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FOREWORD 

Among  the  responsibilities  assigned  to  the  Office  of  the  Manager,  National 
Communications  System,  Is  the  management  of  the  Federal  Telecommunication 
Standards  Program.  Under  this  program,  the  NCS,  with  the  assistance  of  the 
Federal  Telecommunication  Standards  Committee  Identified,  develops,  and 
coordinates  proposed  Federal  Standards  which  either  contribute  to  the 
Interoperability  of  functionally  similar  Federal  telecommunication  systems  or 
to  the  achievement  of  a  compatible  and  efficient  Interface  between  computer  and 
telecommunication  systems.  In  developing  and  coordinating  these  standards,  a 
considerable  amount  of  effort  Is  expended  In  Initiating  and  pursuing  Joint 
standards  development  efforts  with  appropriate  technical  committees  of  the 
International  Organization  for  Standardization,  and  the  International  Telegraph 
and  Telephone  Consultative  Committee  of  the  International  Telecommunication 
Union.  This  Technical  Information  Bulletin  presents  and  overview  of  an  effort 
which  Is  contributing  to  the  development  of  compatible  Federal,  national,  and 
International  standards  In  the  area  of  teleconferencing.  It  has  been  prepared 
to  Inform  Interested  Federal  activities  of  the  progress  of  these  efforts.  Any 
comments.  Inputs  or  statements  of  requirements  which  could  assist  In  the 
advancement  of  this  work  are  welcome  and  should  be  addressed  to: 
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1.0  INTRODUCTION 

This  document  summarizes  work  performed  by  Delta  Information  Systems, 
Inc.  (Delta)  for  the  National  Communications  System  (NCS),  Office  of  Technology 
and  Standards.  This  office  is  responsible  for  the  management  of  the  Federal 
Telecommunications  Standards  Program,  which  develops  telecommunications 
standards,  whose  use  is  mandatory  for  all  Federal  departments  and  agencies. 

This  document  is  a  final  report  for  Task  Order  89-5  on  Contract  DCA100- 
87-C-0078.  The  titles  for  the  contract  and  Task  Order  are  listed  below. 

■  Contract  DCA100-87-C-0078 

Development  of  Federal  Telecommunication  Standards  Relating  to 
Digital  Facsimile  and  Video  Teleconferencing 

■  Task  Order  89-5 

Development  of  a  Federal  Standard  for  a  Video  Codec  operating  at  P  x 
64  Kbps 

For  several  years,  there  has  been  a  major  effort  by  the  CCITT  and  by  ANSI 
(American  National  Standard  Institute)  to  develop  a  standard  for  a  video 
teieconferencing/video  telephone  terminal.  One  major  thrust  of  this  activity  is  that 
the  audio  visual  terminal  be  compatible  with  the  ISDN.  Since  the  basic  building 
block  of  the  ISDN  is  the  B  channel  operating  at  64  Kbps,  the  generic  term  "P  x  64 
Kbps"  refers  to  operation  of  this  audio  visual  terminal  at  integral  values  of  P  up  to 
a  maximum  of  30.  Values  of  P  which  are  of  greatest  interest  are  1 ,  2,  6,  1 2,  24, 
and  30. 

Work  on  the  P  x  64  standard  during  this  report  interval  (June  15,  1989  to 
December  15,  1990)  was  extremely  fruitful.  Highlights  are  listed  below. 

■  There  were  two  meetings  of  the  Specialist's  Group  on  Visual 
Telephony  Coding  resulting  in  a  draft  standard  of  Recommendation 
H.261  entitled  "Video  Codec  for  Audiovisual  Services  at  P  x  64 
Kbit/s. 

■  CCITT  Study  Group  XV,  Working  Group  I  met  in  July,  1 990  to  finalize 
the  drafts  for  the  five  P  x  64  Recommendations  listed  below. 

H.261  Video  codec  for  audiovisual  services  at  P  x  64  kbit/s 
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H.221  Frame  structure  for  a  64  to  1920  kbit/s  channel  in 
audiovisual  teleservices 

H.242  System  for  establishing  communication  between 

audiovisual  terminals  using  digital  channels  up  to  2  Mbit/s 
H.230  Frame  synchronous  control  and  indication  signals  for 
audiovisual  systems 

H.320  Narrow-band  visual  telephone  systems  and  terminal 
equipment 

■  These  five  P  x  64  standards  became  official  CCITT  Recommendations 
on  December  14,  1990.  A  copy  of  the  final  Recommendations  is 
included  in  Appendix  A. 

■  The  NCS  has  developed  a  draft  of  a  Federal  Standard  (Number  1080) 
which  is  based  upon  Recommendation  H.261.  A  copy  of  this  draft  is 
included  in  Appendix  B. 

Section  2.0  of  this  report  summarizes  the  P  x  64  standardization  activity  by 
Delta  during  the  report  interval.  Section  3.0  provides  an  overview  of  all  P  x  64 
Recommendations  other  than  H.261 .  Since  Recommendation  H.261  is  particularly 
critical  to  the  P  x  64  standard,  it  is  discussed  in  more  detail  in  Section  4.0. 
Conclusions  are  drawn  in  Section  5.0. 
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2.0  STANDARDIZATION  ACTIVITY 


Figure  2.1  illustrates  the  relationship  between  those  organizations  which 
actively  participate  in  the  P  x  64  standardization  process.  The  CCITT  is  a  part  of 
the  United  Nations,  and  its  purpose  is  to  develop  formal  "Recommendations"  to 
insure  worldwide  communications  are  accomplished  efficiently  and  effectively. 

The  CCITT  works  in  four-year  cycles,  and  at  the  end  of  each  period  a  complete  set 
of  Recommendations  is  published.  The  "Red  Books"  and  "Blue  Books"  containing 
these  Recommendations  were  published  in  1984  and  1988  respectively. 

In  the  1 984  Red  Books  the  first  Recommendations  for  a  teleconferencing 
codec  (H.120  and  H.130)  were  established.  These  Recommendations  were 
defined  specifically  for  the  European  region  (625  lines;  2.048  Mbit/s  primary  rate) 
and  for  interconnection  between  Europe  and  other  regions.  Since  no 
Recommendation  existed  for  non-European  regions  it  lacked  true  international 
scope,  and  in  1984  the  CCITT  established  a  "Specialists  Group  on  Coding  for 
Visual  Telephony"  to  develop  a  truly  international  Recommendation.  Figure  2.1  ~ 
illustrates  the  location  of  this  group  in  the  CCITT  hierarchy.  The  CCITT  established 
two  objectives  for  the  Specialists  Group:  (1)  to  develop  a  Recommendation  for  a 
video  codec  for  teleconferencing  application  operating  at  the  bit  rates  of  Nx384 
Kbit/s  (N»1  through  5),  and  (2)  to  begin  the  standardization  process  for  a  video 
codec  for  teleconferencing/  video  telephone  application  operating  at  bit  rates  of 
Mx64  Kbit/s  (M  =  1,2). 

The  Specialists  Group  met  seventeen  times  from  1984  through  1989. 
Representatives  from  Canada,  Finland,  France,  Germany,  Italy,  Japan,  Korea, 
Netherlands,  Norway,  Sweden,  the  U.K.,  and  the  United  States  were  members  of 
the  committee. 

At  the  September  meeting  in  1 988,  it  was  determined  that  the  compression 
algorithm  chosen  for  Nx384  Kbit/s  was  sufficiently  flexible  that  it  could  be 
extended,  with  good  performance,  down  to  64  Kbit/s.  At  that  time,  the  Specialists 
Group  shifted  their  focus  to  develop  a  single  Recommendation  to  code  video  at  all 
bit  rates  from  64  Kbit/s  to  2  Mbit/s;  i.e.  to  code  at  rates  of  px64  Kbit/s,  where  the 
key  values  of  p  are  1 ,  2,  6,  24,  and  30. 

In  1989,  a  number  of  organizations  in  Europe,  U.S.  and  Japan  developed 
flexible  codec  systems  to  meet  a  preliminary  specification  of  the  standard.  Various 
systems  were  interconnected  in  the  laboratory  and  by  long  distance 
communication  channels  to  validate  the  Recommendation.  These  tests  were  highly 


FIGURE  2.1  ORGANIZATIONS  CONTRIBUTING  TO  STANDARDS 
FOR  VIDEO  TELECONFERENCING 


successful  and  encouraging.  A  preliminary  version  of  the  final  H.261 
Recommendation  appears  in  the  recent  CCITT  Blue  Book.  However,  this  is 
incomplete,  and  a  final  draft  of  a  more  complete  H.261  was  written  and  submitted 
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to  the  CCITT  for  approval  by  means  of  a  new  Accelerated  Procedure.  The  revised 
H.261  Recommendation  was  formally  approved  by  the  CCITT  on  December  14, 
1990. 

Figure  2.1  also  illustrates  those  domestic  standards  organizations  which 
develop  the  U.S.  technical  positions  on  issues  related  to  video  teleconferencing  and 
video  telephone.  The  T1  committees,  which  are  accredited  by  ANSI  (American 
National  Standards  Institute),  work  on  two  different  aspects  of  teleconferencing: 
the  T1Y1 .1  committee  is  responsible  for  the  coding  algorithms,  while  T1Q1 .5  is 
responsible  for  defining  and  measuring  the  quality  of  service  to  be  provided  by 
teleconference  systems. 

Delta  personnel  attended  a  wide  range  of  meetings  of  standards 
organizations  during  the  report  interval  (June  15,  1989  to  December  15,  1990). 
The  meetings  attended  are  listed  below. 

mu. 

■  July  1 2-89  Denver,  Colorado 

■  April  3,4-90  Dallas,  Texas 

■  July  11-90  Seattle,  Washington 

■  October  3-90  Rockville,  Maryland 

■  October  28,29-90  Chicago,  Illinois 

Joint  Meeting  of  T1Y1.1,  T1Q1.5,  T1S1 

CCITT 

■  June  12-15,  1989  Stuttgart,  Germany 

Specialists  Group 
Review  of  Field  Tests 

■  October  23-26,  1 989  Ipswich,  England 

Editorial  Subgroup  of  Specialists  Group 


■  November  7-10,  1989  Tokyo,  Japan 

Specialists  Group 

Finalized  Draft  H.261  Recommendation 

■  July  16-20,  1990  Geneva,  Switzerland 

Study  Group  XV,  Working  Party  I 
Finalized  Draft  P  x  64  Recommendations 

STATE  DEPARTMENT  STUDY  GROUP  C 

■  June  1 9,  1 990  Washington,  DC 

Developed  the  U.S.  Contribution  for  July,  1990  SG  XV/I 
Meeting 


MIL  STD  188B 

The  Department  of  Defense  is  developing  Standard  MIL  STD  1 88B  for 
teleconferencing.  Delta  personnel  met  with  DoD  representatives  to  contribute  to 
this  standard. 

■  September  26,  1 989  Defense  Communication  Engineering 

Center 

Reston,  Virginia 

■  September  27,  1 990  Ft.  Monmouth,  New  Jersey 


2  -  4 


3.0  OVERVIEW  OF  P  X  64  RECOMMENDATIONS 

As  explained  in  the  above  sections  P  x  64  is  a  generic  term  which 
encompasses  a  broad  class  of  audiovisual  services  defined  in  CCITT 
Recommendations  H.320,  H.261,  H.221,  H.242,  and  H.230.  Basically,  any  audio 
visual  terminal  equipment  must  rigorously  adhere  to  all  of  these  Recommendations 
(including  the  1. 400  series  which  defines  ISON  operations)  to  be  interoperable. 

Since  the  H.320  Recommendation  describes  the  interrelationship  between  all  of  the 
P  X  64  Recommendations  it  will  be  described  first.  The  H.261  is  the  cornerstone 
of  the  P  X  64  Recommendations,  and  is  described  in  a  Section  4.0. 

3.1  H.320  Narrow-band  Visual  Telephone  Systems  and  Terminal  Equipment 

Recommendation  H.320  contains  the  diagram  in  Figure  3.1  which  illustrates 
the  relationship  between  ail  of  the  P  x  64  Recommendations.  The  only  element  In 
this  diagram  which  may  not  be  obvious  is  the  input  from  "Telematic  Equipment". 

In  this  case  "telematic  equipment"  refers  primarily  to  sources  of  still  pictures.  The 

H. 221  Recommendation  specifically  makes  provision  for  multiplexing  still  picture 
signals  with  video  and  audio  signals.  The  still  picture  signals  which  can  be 
accepted  also  must  conform  to  standards  which  either  exist  or  are  in  development. 
There  are  three  general  types  of  still  picture  signals  which  can  be  handled  by  a  P  x 
64  terminal. 

I.  ISO  (International  Standards  Organization)  Still  Picture  Standard 

The  ISO  and  CCITT  have  established  a  Joint  Photographic  Experts  Group 
(JPEG)  to  develop  a  general  purpose  international  standard  for  the  coding  of 
continuous  tone  (gray  scale  or  color)  images.  Although  this  standard  is  in  the  draft 
status,  it  is  well  defined  and  will  prove  to  be  a  valuable  way  of  communicating 
graphics  in  P  x  64/H.320  terminals. 

2.  Group  3  fjcalmllfl 

Group  3  facsimile  is  one  of  the  most  successful  standards  ever  developed. 

It  has  keyed  the  fax  revolution.  The  H.320  terminal  can  handle  signals  conforming 
to  the  CCITT  Group  3  standards  (T.4,  T.30). 

3.  Group  4  Facsimile 

Several  Group  4  facsimile  standards  have  been  finalized  (T.563,  T.5,  T.503, 
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MCU:  Multipoint  Control  Unit 


T.6)  and  some  are  still  in  development.  The  H.320  audiovisual  terminal  can  handle 
Group  4  facsimile  signals. 

One  function  of  the  H.320  Recommendation  is  to  define  the  phases  of 
establishing  a  visual  telephone  call  as  listed  below. 


» 


Phase  A: 
Phase  B1 : 
Phase  CA: 
Phase  CB1 : 
Phase  B2 
(or  CB2): 
Phase  C: 
Phase  D: 
Phase  E: 


Call  set-up,  out-band  signalling 
Mode  initialization  on  initial  channel 
Call  set-up  of  additional  channel(s),  if  relevant 
Initialization  on  additional  channel(s) 

Establishment  of  common  parameters 
Visual  telephone  communication 
Termination  phase 
Call  release 


Another  function  of  Recommendation  H.320  is  the  definition  of  16  different 
types  of  visual  telephone  terminals  and  their  modes  of  operation  (see  Figures  3.2 
and  3.3  respectively). 

3.2  H.221  Frame  Structure  for  a  64  to  1920  Kbit/s  Channel  in  Audiovisual 
Teleservices 

The  purpose  of  this  Recommendation  is  to  define  a  frame  structure  for 
audiovisual  teleservices  in  single  or  multiple  B  or  HO  channels  or  a  single  H11  or 
HI  2  channel  which  makes  the  best  use  of  the  characteristics  and  properties  of  the 
audio  and  video  encoding  algorithms,  of  the  transmission  frame  structure,  and  of 
the  existing  CCITT  Recommendations.  It  offers  several  advantages: 

It  is  simple,  economic  and  flexible.  It  may  be  implemented  on  a  simple 
microprocessor  using  well-known  hardware  principles. 

*  It  is  a  synchronous  procedure.  The  exact  time  of  a  configuration  change  is 
the  same  in  the  transmitter  and  the  receiver.  Configurations  can  be  changed 

•  at  20  ms  intervals. 

It  needs  no  return  link  for  audiovisual  signal  transmission,  since  a 
configuration  is  signalled  by  repeatedly  transmitted  codewords. 

It  is  very  secure  in  case  of  transmission  errors,  since  the  code  controlling  the 
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TABLE  2/H.320 


Typo  X  (Note  2) 


bl  b2  b3  b4  b5 


xxxxxxxxxx 


B 

B 

B 


al  B(H.200/AV.254  audio)  X  X  X  X 


bl  2B(G.711  audio) 


b2  2B(G.722  audio) 


b3  2B(H.200/AV.2S4  audio) 


3B 


4B 


SB 


f  6B 


g  HO 


2H0 


3H0 


J  4H0 


Hll 


SHO 


m  H12 


Type  Z 


B 


X 

X 

X 

X 

X 

X 

X 

X 

Note  1  •  "X*  oeans  the  aode  Is  equipped  with  the  teralnal  of  the  type. 

Note  2  •  Types  Xb4  and  XbS  are  defined  to  take  Into  account  that  H.200/AV.2S4  has 
not  yet  been  recoaoended. 

Note  3  •  Teralnal  of  this  type  aust  have  the  H0-6B  coapatlble  aode  defined  In 
Recoaaendatlon  H.221. 


FIGURE  3.2 
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TABLE  1/H.320 

Comnunlcatlon  modes  of  visual  teleohona 


Visual 
Telephone 
Mode 
(Note  1) 

ISON  Interface 

Coding 

Rate 

(kblt/s) 

IdUM 

Channel 
(Note  2) 

Basic 

Primary 

Rate 

Audio 

Video 

a 

aO 

64 

B 

G.711 

not 

applicable 

•X 

H.200/AV.254 

bl 

G.711 

b 

b2 

128 

2B 

G.722 

b3 

H.200/AV.254 

/253 

(Note  1) 

c 

198 

3B 

d 

256 

4B 

e 

320 

5B 

f 

384 

6B 

H.261 

g 

384 

HO 

applicable 

h 

768 

2H0 

not 

applicable 

1 

1152 

3H0 

G.722 

J 

1536 

3H0 

k 

1536 

Hll 

1 

1920 

5H0 

a 

1920 

H12 

Mota  1  -  (Audio  coding  of  aoda  b3)  In  addition  to  H.200/AV.254,  higher  quality 
audio  coding  such  aa  H.200/AV.2S3  oay  be  uaed  for  this  node. 

Note  2  -  For  oultlple  channels  of  B/HO,  ell  channels  are  synchronized  at  the 
temlnal  according  to  §  2.7/H.221. 


FIGURE  3.3 
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multiplex  is  protected  by  a  double-error  correcting  code. 

It  allows  the  synchronization  of  multiple  64  kbit/s  or  384  kbit/s  connections 
and  the  control  of  the  multiplexing  of  audio,  video,  data  and  other  signals 
within  the  synchronized  multiconnection  structure  in  the  case  of  multimedia 
services  such  as  videoconference. 

This  Recommendation  provides  for  dynamically  subdividing  an  overall 
transmission  channel  of  64  to  1 920  kbit/s  into  lower  rates  suitable  for  audio, 
video,  data  and  telematic  purposes.  The  overall  transmission  channel  is  derived  by 
synchronizing  and  ordering  transmissions  over  from  1  to  6B  connections,  from  1  to 
5  HO  connections,  or  an  H 11  or  HI  2  connection. 

A  single  64  kbit/s  channel  is  structured  into  octets  transmitted  at  8  kHz. 


1 

2 

3 

BlC 

4 

nuBber 

5 

6 

7 

8(SC) 

1  Occat  Numbar 

s 

S 

S 

S 

S 

S 

S 

FAS 

• 

u 

u 

u 

u 

u 

u 

u 

8 

b 

b 

b 

b 

b 

b 

b 

9 

• 

• 

• 

- 

- 

- 

BAS 

, 

C 

C 

C 

C 

C 

C 

C 

16 

h 

h 

h 

h 

h 

h 

h 

17 

a 

a 

a 

a 

a 

a 

a 

(ECS) 

. 

n 

n 

n 

n 

n 

n 

n 

24 

n 

n 

n 

n 

n 

n 

n 

25 

e 

a 

e 

e 

a 

a 

a 

. 

1 

1 

1 

I 

1 

1 

1 

• 

// 

# 

# 

# 

# 

# 

# 

# 

1 

2 

3 

4 

5 

6 

7 

8 

80 

FIGURE  3.4  FRAME  STRUCTURE  OF  A  SINGLE 
64  KBIT/S  CHANNEL  (B-CHANNEL) 

Each  bit  position  of  the  octets  may  be  regarded  as  a  sub-channel  of  8  kbit/s  (see 
Figure  3.4).  The  eighth  sub-channel  is  called  the  Service  Channel  (SC),  containing 
the  two  critical  parts  listed  below. 


FAS  (Frame  Alignment  Signal):  This  8  bit  code  is  used  to  frame  the  80 
octets  of  information  in  a  B  channel. 


BAS  (Bit-rate  Allocation  Signal):  This  8  bit  code  describes  the  capability  of  a 


terminal  to  structure  the  capacity  of  the  channel  or  synchronized  multiple 
channels  in  various  ways,  and  to  command  a  receiver  to  demultiplex  and 
make  use  of  the  constituent  signals  in  such  structures.  This  signal  is  also 
used  for  controls  and  indications. 

Figure  3.5  is  a  list  of  the  various  BAS  codes  defined  in  the  H.221 
Recommendation.  The  codes  are  organized  into  the  8  attributes  listed  below 
(columns  in  Figure  3.5)  each  of  which  can  have  32  possible  values  (rows  in  Figure 
3.5). 


Attribute 

Meanino 

000 

Audio  Coding  Command 

001 

Transfer  Rate  Command 

010 

Video  and  other  Command 

Oil 

Data  Command 

100 

Terminal  Capability  1 

101 

Terminal  Capability  2 

110 

Reserved 

111 

Escape  Codes 

BAS  codes  provide  for  the  following  facilities: 

transmission  at  various  total  rates  and  on  single  and  multiple  channels,  on 
clear  channels  and  on  networks  subject  to  restrictions  to  56  kbit/s  and  its 
multiples. 

audio  transmission,  digitally  encoded  to  various  recommended  algorithms. 

video  transmission,  digitally  encoded  to  a  recommended  algorithm,  with 

provision  for  future  recommended  improvement. 

low-speed  data  (LSD)  within  the  l-channel,  or  TS1  of  a  higher  rate  initial 

channel. 

high-speed  data  (HSD)  in  the  highest-numbered  64  kbit/s  channel  or  time- 
slots  (excluding  the  l-channel). 

data  transmission  within  a  multilayer  protocol,  either  in  the  l-channel  (MLP) 
or  in  capacity  other  than  the  l-channel  (H-MLP). 
an  encryption  control  signal 
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TABLE  AI/H.221 
BAS  numerical  values 


The  column  header  gives  the  attribute  designation  as  bits  <bo,bx.b2): 
the  left-hand  column  gives  the  decimal  value  of  bits  [b3,b4,b5,bg,b7] ;  for 
example,  "channel  y/6”  has  the  value  (001) [10110] .  All  unassigned  values  are 
reserved,  as  are  values  marked  (R) . 


(000) 

(001) 

(010) 

(Oil) 

(100) 

(101) 

(111) 

audio 

trans¬ 

ocher 

LSD/MLP 

audio/ 

data/ 

escape 

command 

fer 

command 

command 

transfer - 

video 

race 

race 

capabi- 

com¬ 

capability  lity 

mand 

[0] 

neutral 

64 

video  off 

LSD  off 

neutral 

var-LSD 

[1] 

2x64 

H.261 

300 

A- law 

300 

[2] 

3x64 

vid- imp (R) 

1200 

M'law 

1200 

[3] 

4x64 

video -ISO 

4800 

G.725-T1 

4800 

[4] 

A- law,  OU 

5x64 

AV-ISO 

6400 

G.725-T2 

6400 

(5] 

M*law,  OU 

6x64 

8000 

Au-16kbic/s8000 

[6] 

G.722,  ml 

384 

encryp-on 

9600 

Au-ISO 

9600 

[7] 

AU-off,  U 

2x384 

encryp-off 

14400 

14400 

[8] 

Note  1 

3x384 

16k 

128 

16k 

[9] 

Mote  1 

4x384 

24k 

192 

24k 

[10] 

5x384 

32k 

256 

32k 

[11] 

1536 

40k 

40k 

[12] 

1920 

48k 

512 

48k 

[13] 

Au-ISO-64 

128 

56k 

768 

56k 

[14] 

Au- ISO- 128 

192 

62.4k 

62.4k 

[15] 

Au- ISO- 192 

256 

64k 

1152 

64k 

[16] 

Au- ISO-256 

freeze -pic 

MLP-off 

IB 

MLP-4k 

HSD 

[17] 

Au- ISO- 384 

loss  i.c. 

fast-update  MLP-4k 

2B 

MLF-6.4k 

H.230 

[18] 

A- law, OF 

chaxi.^2 

Au-loop 

MLP-6.4k 

3B 

var-MLF 

Data-apps 

[19] 

>i-law,0F 

chan. #3 

Vid- loop 

var-HLP 

4B 

(R-SBE) 

[20] 

chan. #4  Dig- loop 

5B  .. 

QCIF 

(R-SBE) 

[21] 

chan. #5  Loop-off 

dtt-l(R) 

6B 

CIF 

(R-SBE) 

[22] 

chan.;|t6 

dtl-2(R) 

restrict 

1/29.97 

(R-SBE) 

[23] 

512 

dti-3(R) 

6B-H0-comp 

2/29.97 

(R-SBE) 

[24] 

G.722,m2(NoCe2)768 

HO 

3/29.97 

cap -mark 

[25] 

G.722.m3(NoCa2) 

6B'H0-comp 

2H0 

4/29.97 

start-MBE 

[26] 

(Au-40k) 

1152 

No-comp  6B-H0 

3H0 

V-imp(R) 

[27] 

(Au-32k) 

restrict 

4H0 

video- ISO 

[28] 

(Au-24k) 

derestrict 

5H0 

AV-ISO 

[29] 

Au-16kblc/s 

1472 

1472 

eac-CF(R) 

[30] 

(Au-<16k) 

Hll 

encryp. 

ns -cap 

[31] 

Au-off,  F 

var-LSD 

H12 

HBE-cap 

ns -comm 

Note  1  -  These  codes  are  listed  in  Recommendation  G.72S  with  reference  to  an 
"application  channel";  such  a  channel  has  not  been  defined,  the  concept  having 
been  superseded  by  chat  of  LSD/MLP;  therefore  these  codes  should  not  be  used. 

Note  2  -  These  codes  are  listed  in  Recommendation  G.72S  with  reference  to 
"data";  however,  the  nature  of  such  data  (video,  LSD,  MLP,  ECS)  must  be 
specified  by  further  commands  (001) ,  (010) ,  (011) . 

FIGURE  3.5 
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loopback  towards  the  network  for  maintenance  purposes, 
signalling  for  control  and  indications. 

a  message  system  for,  inter  alia,  conveying  information  concerning 
equipment  manufacturer  and  type. 

in  general,  there  are  two  types  of  BAS  codes  --  1)  command,  and  2) 
capability.  When  a  "command"  code  is  received,  the  mode  of  operation  is 
changed.  "Capability"  BAS  codes  indicate  the  ability  of  a  terminal  to  receive  ad 
properly  treat  the  various  types  of  signals.  It  follows  that  having  received  a  set  of 
"capability"  codes  from  the  remote  terminal  Y,  terminal  X  must  not  transmit  signals 
outside  that  declared  range. 

The  reader  will  note  in  Figure  3.5,  that  Attribute  111A/alue  18  is  defined  as 
"Data-apps"  which  means  "applications  within  LSD/HSD  (low  speed  data/high 
speed  data)  channels:  a  32-code  table,  see  Table  A3/H.221"  (Figure  3.6).  Figure 
3.6  shows  the  various  still  picture  modes  which  can  be  used  to  supplement  the  ~ 
video  teleconference. 

The  reader  will  also  note  in  Figure  3.5  that  Attribute  1 1 1 /Values  30  and  31 
mean  "Non-Standard  Capability"  and  "Command"  respectively.  This  permits  a 
H.320  terminal  to  operate  in  a  proprietary  non-standard  mode. 

3.3  H.242  System  for  Establishing  Communication  Between  Audiovisual 

Terminals  using  Digital  Channels  up  to  2  Mbit/s 

Recommendation  H.320  defines  a  number  of  phases  in  the  establishment  of 
a  visual  telephone  call  which  precede  and  succeed  the  actual  communication  itself. 

Phase  A:  Call  set-up,  out-band  signalling 
Phase  B1 :  Mode  initialization  on  initial  channel 
Phase  CA:  Call  set-up  of  additional  channel(s),  if  relevant 
Phase  CB1 :  Initialization  on  additional  channel(s) 

Phase  B2  (or  CB2):  Establishment  of  common  parameters 
Phase  C:  Visual  Telephone  Communication 
Phase  0:  Termination  Phase 
Phase  E:  Call  release 

Recommendation  H.242  defines  the  detailed  "handshake”  protocol  and 
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TABLE  A3/H.221 


The  column  header  gives  che  attribute  designation  as  bits  (bQ,bx,b2) 
the  left-hand  column  gives  the  decimal  value  of  bits  [b3,b4,b5,bg,b7] .  All 
assigned  values  are  reserved,  as  are  values  marked  (R) . 


(101) 


rnrnmunrf^  (Oil) 


[0] 

tl] 

[2] 

[3] 

[4] 
[51 
[6] 

[7] 

[8] 

[9] 

[10] 
[11] 
[12] 

[13] 

[14] 

[15] 

[16] 

[17] 

[18] 

[19] 

[20] 
[21] 
[22] 

[23] 

[24] 

[25] 

[26] 

[27] 

[28] 

[29] 

[30] 

[31] 


ISO-SP  baseline  on  LSD 
ISO-SP  baseline  on  HSD 
ISO-SP  spatial 
ISO-SP  progressive 
ISO-SP  arithmetic 


Graphics  cursor 


Group  3  Fax 
Grottp  4  Fax 


V.120  LSD 
V.120  HSD 


ISO-SP  on  in  LSD 
ISO-SP  on  in  HSD 


Cursor  data  on  in  LSD 


Fax  on  in  LSD 
Fax  on  in  HSD 


V.120  LSD 
V.120  HSD 
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procedures  which  are  employed  by  H.320  terminals  in  these  preliminary  phases. 
Major  topics  covered  in  this  Recommendation  are  listed  below. 

Basic  sequences  for  in-channel  procedures 
o  Capability  exchange  sequence  A 

o  Mode  switching  sequence  B 

o  Frame  reinstatement  sequence  C 

Mode  initialization,  dynamic  mode  switching  and  mode  0  forcing 

Recovery  from  fault  conditions 

o  Unexpected  loss  of  synchronization  or  frame  alignment 

o  Recovery  from  loss  of  connection^) 

Network  consideration:  Call  connection,  disconnection  and  call  transfer 
Procedures  for  activation  and  deactivation  of  data  channels 
Procedures  for  operation  of  terminals  in  restricted  networks 
o  56  Kbit/s  network 

o  56/64  network  interworking 

3.4  H.230  Frame  Synchronous  Control  and  Indication  Signais  for  Audiovisual 
Systems 

Digital  audiovisual  services  are  provided  by  a  transmission  system  in  which 
the  relevant  signals  are  multiplexed  onto  a  digital  path.  In  addition  to  the  audio, 
video,  user  data  and  telematic  information,  these  signals  include  information  for 
the  proper  functioning  of  the  system.  The  additional  information  has  been  named 
"control  and  indication"  (C&l)  to  reflect  the  fact  that  while  some  bits  are  genuinely 
for  "control",  causing  a  state  change  somewhere  else  in  the  system,  others 
provide  for  indications  to  the  users  as  to  the  functioning  of  the  system. 

Recommendation  H.230  has  two  primary  elements.  First,  it  defines  the  C&l 
symbols  related  to  video,  audio,  maintenance,  and  multipoint.  Second,  it  contains 
a  table  of  BAS  escape  codes  which  clarifies  the  circumstances  under  which  some 
C&l  functions  are  mandatory  and  others  optional.  The  reader  will  note  on  Figure 

3.5  that  the  H.230  escape  code  is  signalled  by  Attribute  111  and  Value  17. 

3.5  Audio  Coding  (AV.250) 

The  BAS  codes  of  H.221  are  used  to  signal  a  wide  range  of  possible  audio 
coding  modes.  The  most  prominent  modes  define  existing  CCITT 


3  -  11 


Recommendations  G.711  and  G.722.  Recommendation  G.711  (Pulse  Code 
Modulation  of  Voice  Frequencies)  is  used  for  narrowband  speech  since  it  samples 
only  at  8,000  samples/sec.  and  encodes  to  8  bits/sample  for  a  transmission  rate  of 
64  Kbps.  Recommendation  G.722  (7kHz  Audio-Coding  with  64  Kbit/s)  describes 
the  characteristics  of  an  audio  (50  to  7  000  Hz)  coding  system  which  may  be  used 
for  a  variety  of  higher  quality  speech  applications.  The  coding  system  uses  sub¬ 
band  adaptive  differential  pulse  code  modulation  (SB-ADPCM)  within  a  bit  rate  of 
64  Kbit/s.  In  the  SB-ADPCM  technique  used,  the  frequency  band  is  split  into  two 
sub-bands  (higher  and  lower)  and  the  signals  in  each  sub-band  are  encoded  using 
ADPCM.  The  system  has  three  basic  modes  of  operation  corresponding  to  the  bit 
rates  used  for  7  kHz  audio  coding:  64,  56,  and  48  kbit/s. 

BAS  codes  have  been  reserved  for  future  audio  standards  which  are  now  in 
development.  Bit  rates  include  40,  43,  24,  and  16  Kbps.  Of  particular  importance 
is  the  16  Kbps  (AV.254)  which  is  necessary  to  provide  a  complete  audio  visual 
service  in  one  B  channel. 

3.6  Multipoint 

At  this  time,  standards  do  not  exist  for  multipoint  operation  of  H. 320/P  x  64 
terminals.  However,  work  is  underway  on  three  CCITT  Recommendations  to  fill 
this  void.  Copies  of  these  three  Recommendations  illustrating  their  very 
preliminary  form  are  included  in  Appendix  C. 

AV.231  Multipoint  control  unit  for  audiovisual  services 

AV.243  System  for  establishing  communication  between  three  or  more 
audiovisual  terminals  using  digital  channels  up  to  2mbit/s 

AV.440  Call-control  procedures  for  real-time  audiovisual  conference 
calls 
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4.0  OVERVIEW  OF  RECOMMENDATION  H.261  (VIDEO  CODEC) 

Figure  4.1  is  a  functional  block  diagram  of  the  video  codec  as  defined  in 
Recommendation  H.261 .  The  heart  of  the  system  is  the  source  coder  which 
compresses  the  incoming  video  signal  by  reducing  redundancy  inherent  in  the  TV 
signal.  The  multiplexer  combines  the  compressed  data  with  various  side 
information  which  indicates  alternative  modes  of  operation.  A  transmission  buffer 
is  employed  to  smooth  the  varying  bit  rate  from  the  source  encoder  to  adapt  it  for 
the  fixed  bit  rate  communication  channel.  A  transmission  coder  includes  functions 
such  as  forward  error  control  to  prepare  the  signal  for  the  data  link. 


FIGURE  4.1  BLOCK  DIAGRAM  OF  THE  VIDEO  CODEC 


One  of  the  most  challenging  problems  to  be  solved  by  the  codec  was  the 
reconciliation  of  the  incompatibility  between  European  TV  standards  (PAL,  SECAM) 
and  those  in  most  other  areas  of  the  world  (NTSC).  PAL  and  SECAM  employ  625 
lines  and  a  50  Hz  field  rate  while  NTSC  has  525  lines  and  a  60  Hz  field  rate.  This 
conflict  was  resolved  by  adopting  a  Common  Intermediate  Format  (CIF)  and  QCIF 
(Quarter  CIF)  as  the  picture  structure  which  must  be  employed  for  any 
transmission  adhering  to  H.261.  The  CIF  and  QCIF  parameters  are  defined  in  Table 
4.1. 

The  QCIF  format,  which  employs  half  the  CIF  spatial  resolution  in  both 
horizontal  and  vertical  directions,  is  the  mandatory  H.261  format:  full  CIF  is 
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CIF 

QCIF 

Coded  Pictures  per  Second 

(or  integral 
29.97  submultiples) 

Coded  Luminance  pixels  per  line 

352 

176 

Coded  Luminance  lines  per  picture 

288 

144 

Coded  Color  pixels  per  line 

176 

88 

Coded  Color  lines  per  picture 

144 

72 

TABLE  4.1  CIF  AND  QCIF  PARAMETERS 

optional.  It  is  anticipated  that  QCIF  will  be  used  for  videophone  applications  where 
head-and'Shoulders  pictures  are  sent  from  desk  to  desk.  Conversely,  it  is  assumed 
that  the  full  CIF  format  will  be  used  for  teleconferencing  where  several  people 
must  be  viewed  in  a  conference  room. 

Figure  4.2  is  a  functional  block  diagram  outlining  the  H.261  source  coder. 
Interframe  prediction  is  first  carried  out  in  the  pixel  domain.  The  prediction  errors 
are  encoded  by  the  Discrete  Cosine  Transform  using  blocks  of  8  pels  x  8  pels.  The 
Transform  coefficients  are  next  quantized  and  fed  to  the  multiplexer.  Motion 
compensation  is  included  in  the  prediction  on  an  optional  basis. 

PICTURE  STRUCTURE 

In  the  encoding  process,  each  picture  is  subdivided  into  Groups  of  Blocks 
(GQB).  As  shown  in  Figure  4.3,  the  CIF  picture  is  divided  into  12  GOB's  while 
QCIF  has  only  three  GQB's.  From  the  GOB  level  down,  the  structure  of  CIF  and 
QCIF  is  identical.  A  header  at  the  beginning  of  the  GOB  permits  resynchronization 
and  changing  the  coding  accuracy. 

Each  GOB  is  further  divided  into  33  macroblocks,  as  shown  in  Figure  4.4. 
The  macrobiock  header  defines  the  location  of  the  macroblock  within  the  GOB,  the 
type  of  coding  to  be  performed,  possible  motion  vectors,  and  which  blocks  within 
the  macroblock  will  actually  be  coded.  There  are  two  basic  types  of  coding.  In 
Intra  coding,  coding  is  performed  without  reference  to  previous  pictures.  This 
mode  is  relatively  rare,  but  is  required  for  forced  updating,  and  every  macroblock 
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RGURE  4.4  ARRANGEMENT  OF  MACROBLOCKS  IN  A  GOB 


must  occasionally  be  Intra  coded  to  control  the  accumulation  of  inverse  transform 
mismatch  error.  The  more  common  coding  type  is  inter,  in  which  only  the 
difference  between  the  previous  picture  and  the  current  one  is  coded.  Of  course, 
for  picture  areas  without  motion,  the  macroblock  does  not  have  to  be  coded  at  ail. 
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Each  macroblock  is  further  divided  into  six  blocks,  as  shown  in  Figure  4.5. 


Luminanca  Blua  Rad 

FIGURE  4.5  ARRANGEMENT  OF  BLOCKS  IN  A  MACROBLOCK 


Four  of  the  blocks  represent  the  luminance,  or  brightness,  while  the  other  two 
represent  the  red  and  blue  color  differences.  Each  block  is  8  x  8  pixels,  so  it  can 
be  seen  that  the  color  resolution  is  half  of  the  luminance  resolution  in  both 
dimensions. 

EXAMPLE  OF  BLOCK  CODING 

Figure  4.6  shows  a  simple  example  of  how  each  8x8  block  is  coded.  In  ' 
this  case,  Intra  coding  is  used,  but  the  principle  is  the  same  for  Inter  coding. 

Figure  4.6a  shows  the  original  block  to  be  coded.  Without  compression,  this 
would  take  8  bits  to  code  each  of  the  64  pixels,  or  a  total  of  51 2  bits.  First,  the 
block  is  transformed,  using  the  two-dimensional  Discrete  Cosine  Transform  (DCT), 
giving  the  coefficients  of  Figure  4.6b.  Note  that  most  of  the  energy  is 
concentrated  into  the  upper  left-hand  corner  of  the  coefficient  matrix.  Next,  the 
coefficients  of  Figure  4.6b  are  quantized  with  a  step  size  of  6.  (The  first  term 
{DC}  always  uses  a  step  size  of  8.)  This  produces  the  values  of  Figure  4.6c, 
which  are  much  smaller  in  magnitude  than  the  original  coefficients  and  most  of  the 
coefficients  become  zero.  The  larger  the  step  size,  the  smaller  the  values 
produced,  resulting  in  more  compre%sion. 

The  coefficients  are  then  reordered,  using  the  Zig-Zag  scanning  order  of 
Figure  4.7.  All  zero  coefficients  are  replaced  with  a  count  of  the  number  of  zero's 
before  each  non-zero  coefficient  (RUN).  Each  combination  of  RUN  and  VALUE 
produces  a  Variable  Length  Codb  (VbC)  that  is  sent  to  the  decoder.  The  last  non¬ 
zero  VALUE  is  followed  by  an  End  of  Block  (EOB)  code.  The  total  number  of  bits 
used  to  describe  the  block  is  25,  a  compression  of  20:1. 

At  the  decoder  (and  at  the  coder  to  produce  the  prediction  picture),  the  step 
size  and  VALUE'S  are  used  to  reconstruct  the  inverse  quantized  coefficients. 
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FIGURE  4.6  SAMPLE  INTRA  BLOCK  CODING 


which,  as  shown  In  Figure  4.6e  are  similar  to,  but  not  exactly  equal  to,  the  original 
coefficients.  When  these  coefficients  are  inverse  transformed,  the  result 
of  Figure  4.6f  is  obtained.  Note  that  the  differences  between  this  block  and  the 
original  block  are  quite  small. 

MOTION  COMPENSATION 

The  operation  of  motion  compensation  is  shown  in  Figure  4.8.  Block  "A"  is 
a  block  in  the  current  picture  that  is  to  be  coded.  Block  "B"  is  the  block  at  the 
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same  position  as  ”A”  but  in  the  picture  that  was 
previously  stored  in  both  coder  and  decoder. 

Because  of  image  motion,  block  ”A"  more  closely 
resembles  the  pixel  data  from  block  "C"  than  that 
from  block  "B”.  The  displacement  of  block  "C 
from  block  "B”,  measured  in  pixels  in  x  and  y 
directions,  is  the  motion  vector.  The  pixel-by- 
pixel  difference  between  blocks  "A"  and  "C”  is 
transformed  and  coded.  The  motion  vector  and 
code  data  are  transmitted  to  the  decoder,  where 

the  inverse  transformed  block  data  is  added  to  ^  .. 

^  ^  ^  FIGURE  4.7  SCANNING 

the  data  in  block  C  pointed  to  by  the  motion  ORDER  IN  A  BLOCK 


FIGURE  4.8  INTER-FRAME  CODING 
WITH  MOTION  VECTORS 
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vector,  artd  placed  in  the  block  "A”  position. 

The  use  of  motion  vectors  is  optional  in  the  coder,  where  the  calculation  of 
the  optimum  motion  vectors  is  complex,  but  required  in  the  decoder,  where  the 
reconstruction  of  the  motion  is  relatively  simple. 

FLEXIBILITY  OF  STANDARD 

The  H.261  standard  does  not  define  all  aspects  of  image  coding  and 
decoding.  Rather  it  is  just  a  interoperability  specification,  guaranteeing  that  any 
codecs  manufactured  according  to  the  standard  will  be  able  to  communicate  with 
each  other.  This  still  allows  considerable  freedom  for  manufacturers  to  offer  better 
performance,  and  new  developments  may  be  able  to  be  incorporated.  (This  is  in 
contrast  with  the  G.722  audio  standard,  where  the  coding  algorithm  is  rather 
precisely  defined.)  For  example,  the  encoder  strategy  is  not  defined.  Which  blocks 
will  be  encoded,  with  what  type  of  code,  and  with  what  accuracy  is  under  control 
of  the  designer.  While  there  is  less  freedom  for  the  decoder,  post  processing,  such 
as  filtering  or  interpolation,  can  be  used  to  improve  the  appearance  of  the  image 
and  is  under  control  of  the  designer. 

Furthermore,  the  P  x  64  standards  permit  two  codecs  to  negotiate  to  an 
altogether  different  algorithm  that  they  both  incorporate,  with  the  H.261  algorithm 
becoming  a  fail-back  mode  for  codecs  of  different  manufacture. 
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5.0  SUMMARY  AND  CONCLUSIONS 

Work  during  this  report  interval  on  the  P  x  64  standards  has  been  unusually 
productive.  Five  CCITT  Recommendations  (H.320,  H.261,  H.221,  H.242,  H.230) 
were  finalized  in  December,  1 990.  These  Recommendations  completely  define  an 
audio  visual  terminal  for  videophone  and  video  teleconferencing  applications. 
Products  conforming  to  these  Recommendations  are  already  in  the  marketplace, 
and  it  is  anticipated  that  a  revolution  in  video  telephony  will  occur  which  will  be 
similar  to  that  which  occurred  in  the  facsimile  market  when  the  Group  3  standard 
was  finalized.  This  revolution  will  occur  for  the  following  reasons. 

The  standard  provides  picture  quality  which  is  at  least  competitive 
with  proprietary  systems  in  the  marketplace. 

The  picture  quality  will  continually  improve  due  to  competitive  market 
pressure. 

The  system  is  very  flexible  permitting  a  wide  range  of  operational 
modes  video  operation,  voice  quality,  still  imagery,  transmission  bit 
rates,  etc. 

Codec  cost  will  rapidly  drop  due  to  the  availability  of  low  cost  VLSI 
chips  and  high  volume  production. 

Communication  costs  will  drop  as  the  ISDN  is  introduced  and  traffic 
volume  increases. 
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I.  RaeoamandAtlon  H.221 

FRAME  STRUCTURE  FOR  A  64  TO  1920  kblt/s  CHANNEL 
IN  AUDIOVISUAL  TELESERVICES^ 

CONTENTS 

Introduction 

1.  Buie  principle 

1.1  Fraae  alignment  signal  (FAS) 

1.2  Bit*rate  allocation  signal  (BAS) 

1.3  Encryption  control  signal  (ECS) 

1.4  Remaining  capacity 

2.  Frame  alignment 

2 . 1  General 

2 . 2  Multiframe  structure 

2.3  Loss  and  recovery  of  frame  alignment 

2.4  Loss  and  recovery  of  multlframe  alignment 

2.5  Procedure  to  recover  octet  timing  from  frame  alignment 
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2.5.2  Particular  cases 

2.5.3  Search  for  frame  alignment  signal  (FAS) 

2.6  Description  of  the  CRC4  procedure 
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2.7  Synchronization  of  multiple  connections 

2.7.1  Multiple  B  connections 


^  This  RecooDiendation  completely  replaces  the  text  of  Recommendations  H.221 
and  H.222  published  in  Fascicle  III. 6  of  the  Blue  Book. 
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3. 

3.1 

3.2 

3.3 
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Annex  2: 


Multiple  HO  connections 

Bit-rate  allocation  signal 

Encoding  of  the  BAS 

Values  of  the  BAS 

Procedures  for  the  use  of  BAS 

Definitions  and  tables  of  BAS  values 

Frane  structure  for  intervoricing  between  a  64  Icbit/s  terminal  and  a 
56  kbit/s  terminal 


Introduction 

The  purpose  of  this  Recommendation  is  to  define  a  frame  structure  for 
audiovisual  teleservices  in  single  or  multiple  B  or  HO  channels  or  a  single  Hll 
or  H12  channel  which  makes  the  best  use  of  the  characteristics  and  properties  of 
the  audio  and  video  encoding  algorithms,  of  the  transmission  frame  stnieture  and 
of  the  existing  CCITT  Recommendations.  It  offers  several  advantages; 

•  It  takes  into  account  CCITT  Recommendations  such  as  G.704, 

X. 30/1. 461,  etc.  It  may  allow  the  use  of  existing  hardware  or 
software . 

•  It  is  simple,  economic  and  flexible.  It  may  be  implemented  on  a 
simple  microprocessor  using  well-known  hardware  principles. 

-  It  is  a  synchronous  procedure.  The  exact  time  of  a  configuration 
change  is  the  same  in  Che  transmitter  and  the  receiver. 
Configurations  can  be  changed  at  20  ms  intervals. 

It  needs  no  return  link  for  audiovisual  signal  transmission, 
since  a  configuration  is  signalled  by  repeatedly  transmitted 
codewords . 

It  is  very  secure  in  case  of  transmission  errors,  since  the  code 
controlling  the  multiplex  is  protected  by  a  double-error 
correcting  code. 

-  It  allows  Che  synchronization  of  multiple  64  kbit/s  or  384  kbit/s 
connections  and  the  control  of  the  multiplexing  of  audio,  video, 
data  and  ocher  signals  within  the  synchronized  mulciconnection 
structure  in  the  case  of  multimedia  services  such  as 
videoconference . 

It  can  be  used  to  derive  octet  synchronization  in  networks  where 
this  is  not  provided  by  ocher  means. 

It  can  be  used  in  multipoint  configurations,  where  no  dialogue  is 
needed  to  negotiate  the  use  of  a  data  channel. 
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It  provides  a  variety  of  data  bit- rates  (from  300  bit/s  up  to 
almost  2  Mbit/s)  to  the  user. 

1.  Basic  ortneiola 

This  Recommendation  provides  for  dynamically  subdividing  an  overall 
transmission  channel  of  64  to  1920  Icbit/s  into  lower  races  suitable  for  audio, 
video,  data  and  telematics  purposes.  The  overall  transmission  channel  is  derived 
by  S3mchronizing  and  ordering  transmissions  over  from  1  to  6  B  connections,  from 
1  to  5  HO  connections,  or  an  Hll  or  H12  connection.  The  first  connection 
established  is  the  Initial  connection  and  carries  the  Initial  channel  in  each 
direction.  The  additional  connections  carry  additional  channels. 

The  total  rate  of  transmitted  information  is  called  the  "transfer 
rats" ;  it  is  possible  to  fix  the  transfer  rate  less  chan  Che  capacity  of  Che 
overall  transmission  channel  (values  listed  in  Annex  1) . 

A  single  64  kbic/s  channel  is  structured  into  octets  transmitted  at 
3  kHz.  Each  bit  position  of  the  octets  may  be  regarded  as  a  sub-channel  of 
8  kbic/s  (see  Figure  la).  The  eighth  sub-channel  is  called  the  Service  Channel 
(SC),  consisting  of  several  parts  as  described  in  sections  1.1  -  1.4  below. 

An  HO,  Hll  or  H12  channel  may  be  regarded  as  consisting  of  a  number  of 
64  kbit/s  time -a lots  (TS)  (see  Figure  lb).  The  lowest  numbered  time-slot  is 
structured  exactly  as  described  for  a  single  64  kbic/s  channel,  while  the  ocher 
TS  have  no  such  structure.  In  the  case  of  multiple  B  or  HO  channels,  all 
channels  have  a  frame  structure;  chat  in  the  initial  channel  controls 
most  functions  across  the  overall  transmission,  while  the  frame  structure  in  the 
additional  channels  is  used  for  synchronization,  channel  numbering  and  related 
controls . 


The  term  "I-channel"  is  applied  to  the  initial  or  only  B-channel,  to 
TSl  of  initial  or  only  HO  channel,  and  to  TSl  of  Hll,  H12  channels. 
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I2S  microseconds 


FIGURE  l(b)/H.221 


(HO.  Hll.  H12  channels) 


1.1  Frame  alignment  signal  (FAS) 

This  signal  scructures  the  I -channel  and  other  framed  64  kbit/s 
channels  into  frames  of  80  octets  each  and  multi.frames  (MF)  of  16  frames  each. 
Each  multiframe  is  divided  into  eight  2-frans  s\ib-multiframes  (SMF) .  The  term 
"frame  alignment  signal"  (FAS)  refers  to  bits  1-8  of  the  SC  in  each  frame.  In 
addition  to  framing  and  multiframing  information,  control  and  alarm  information 
may  be  inserted  in  the  FAS,  as  well  as  error  check  information  to  control  end- 
to-end  error  performance  and  to  check  frame  alignment  validity.  Other  time-slots 
are  aligned  to  the  first. 

The  bits  are  transmitted  to  line  in  order,  bit  1  first. 

Uhen  an  8  kHz  network  clock  is  provided,  FAS  is  transmitted  and 
received  in  the  least  significant  bit  of  the  octet  within  each  12S  microsecond, 
e.g.,  in  an  ISDN  basic  or  primary  race  interface. 

The  FAS  can  be  used  to  derive  receive  octet  timing  when  it  is  not 
provided  by  the  network.  However,  in  the  latter  case,  the  terminal  cannoi 
transmit  FAS  with  correct  alignment  into  the  octet  timed  part  of  the  network  and 
cannot  intercommunicate  with  terminals  which  rely  only  on  network  timing  for 
octet  alignment. 
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1.2  Bie-r«f  allocation  signal  (BAS) 

Blcs  9-16  of  cha  SC  in  each  frame  are  referred  co  as  BAS.  This  signal 
allows  Che  cransmlssion  of  codewords  Co  describe  che  capability  of  a  cerminal  co 
structure  che  capacity  of  che  channel  or  synchronized  multiple  channels  in 
various  ways,  and  co  command  a  receiver  to  demultiplex  and  make  use  of  che 
consclcuenc  signals  in  such  structures.  This  signal  is  also  used  for  controls 
and  indications . 

Note  -  For  some  countries  having  56  kbic/s  channels,  che  net  available  bit  races 
will  be  8  kbic/s  less.  Interworking  between  a  64  kbic/s  cerminal  and  a  56  kbic/s 
terminal  is  established  according  to  the  frame  structure  in  Annex  2. 

1.3  Encryption  control  signal  (ECS3 

A  future  encryption  capability  may  require  a  dedicated  transmission 
channel.  It  is  anticipated  chat  800  bic/s  should  be  provided  when  required  by 
allocating  che  bits  17-24  of  che  Service  Channel.  This  reduces  variable  data  and 
video  transmission  rates  herein  by  800  bic/s.  The  800  bic/s  is  referred  to  as 
che  ECS  Channel. 

1.4  Remaining  capacity 

The  remaining  capacity  (including  che  rest  of  che  service  channel), 
carried  in  bits  1-8  of  each  octet  in  the  case  of  a  single  64  kbiC/s  connection, 
may  convey  a  variety  of  signals  within  che  framework  of  a  multimedia  service, 
under  che  control  of  che  BAS.  Some  examples  follow: 

voice  encoded  at  56  kbic/s  using  a  truncated  form  of  PCM  of  CCITT 
Recommendation  G.711  (A- law  or  M*law); 

voice  encoded  at  16  kbic/s  and  video  at  46.4  kbic/s; 

voice  encoded  at  56  kbic/s  with  a  bandwidth  50  •  7000  Hz  (subband 
AOFCM  according  co  CCITT  Recommendation  G.722);  che  coding 
algorithm  is  also  able  co  work  at  48  kbic/s  -  data  can  then  be 
dynamically  inserted  at  up  co  14.4  kbic/s; 

still  pictures  coded  at  56  kbic/s; 

data  at  56  kbit/s  inside  an  audiovisual  session  (e.g.,  file 
transfer  for  communicating  between  personal  computers). 

2.  vi-mmM  «i4pimenc 

2 . 1  Gemeral 

An  80-octac  frame  length  produces  an  80-bic  word  in  the  Service 
Channel.  These  80  bits  are  numbered  1-80.  Bits  1-8  of  che  Service  Channel  in 
every  frame  constitute  the  FAS  (see  Figure  2/H.221),  whose  concent  is  as 
follows : 

mulciframe  structure  (see  section  2.2); 
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frame  alignment  word  (FAW) ; 

-A-bit"; 

"E-"  and  "C-bics"  (see  section  2.6). 


SUCCESSIVE  Bit  # 
FRAMES 

Even  frames 

Odd  frames 

Note  1 

1 

0  110  11 

1 

Frame  Alignment  Word  -  Note  2 

Note  1 

1 

Not 

ce  2 

A 

Note  3 

E 

Note  4 

Cl 

C2 

C3 

C4 

Note  1  -  See  section  2.2  and  Figure  3/H.221. 

Note  2  -  The  first  seven  bits  of  the  Frame  Alignment  Word  are  in  the  even 
frames.  The  eighth  bit  of  the  FAW  in  the  odd  frame  is  the  complement  of  the 
first  FAW  bit  in  order  to  avoid  simulation  of  FAW  by  a  frame -repetitive 
pattern. 

Note  3  •  A-bit  loss  of  fflultiframe  alignment  indication  (0  -  alignment; 

1  «  loss) . 

Note  A  -  The  use  of  bits  E  and  C1-C4  is  described  in  section  2.6  (0  -  no  error 
or  CRC  not  in  use;  1  -  error). 


FIGURE  2/H.221 

Assignment  of  bits  1-8  of  the  service  channel  in  each  frame 


The  FAW  conalsta  of  "0011011"  in  bits  2-8  of  the  FAS  in  even  frames, 
complemented  by  an  "1"  in  bit  2  of  the  succeeding  odd  frame. 

The  "A-bit"  of  the  I -channel  is  set  to  zero  whenever  the  receiver  is  in 
multiframe  alignment,  and  is  set  to  ”1"  otherwise  (see  section  2.3);  for 
additional  channels,  see  section  2.7.1. 

2.2  Multiframe  structure 

Each  multiframe  contains  16  consecutive  frames  numbered  0  to  15  divided 
into  eight  sub -multlf raffles  of  two  frames  each  (Figure  3).  The  multiframe 
alignment  signal  is  located  in  bit  1  of  frames  1-3-5-7-9-11  and  has  the  form 
001011.  Bit  1  of  frame  15  remains  reserved  for  future  use.  The  value  is  fixed  at 
0. 


Bit  1  of  frames  0-2-4-6  may  be  used  for  a  modulo  16  counter  to  number 
multiframes  in  descending  order.  The  least  significant  bit  is  transmitted  in 
frame  0,  and  the  moat  significant  bit  in  frame  6.  The  receiver  uses  the 
multiframe  numbering  to  equalize  out  the  differential  delay  of  separate 
connections,  and  to  synchronize  the  received  signals. 
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Blc  1  of  fraae  8  is  sec  co  1  when  mulclfraaes  are  numbered  and  is  sec 
CO  0  when  they  are  not. 

Blc  1  of  frames  10*12-13  muse  be  used  co  number  each  channel  in  a 
mulclconnecclon  scrucCure  so  chac  Che  dlscanc  receiver  can  place  Che  occecs 
received  in  each  12S  microseconds  in  che  correcC  order. 

Informaclon  bits  in  che  mulciframa  should  be  validaced  by,  for  example, 
being  received  consiscencly  for  chree  mulclframes. 


Sub- 

Bits  1 

to  8 

of  che 

Service 

Channel 

multi- 

Frame 

in 

every 

frame 

frame 

1 

2 

3 

4 

5 

6 

7 

8 

0 

Ml 

0 

0 

1 

1 

0 

1 

1 

SMF  1 

1 

0 

1 

A 

E 

Cl 

C2 

C3 

C4 

2 

N2 

0 

0 

1 

1 

0 

1 

1 

SMF  2 

3 

0 

1 

A 

E 

Cl 

C2 

C3 

C4 

4 

N3 

0 

0 

1 

1 

0 

1 

1 

SMF  3 

5 

1 

1 

A 

E 

Cl 

C2 

C3 

C4 

6 

M4 

0 

0 

1 

1 

0 

I 

1 

SMF  4 

7 

0 

1 

A 

E 

Cl 

C2 

C3 

C4 

Mulciframe 

8 

N5 

0 

0 

1 

1 

0 

1 

1 

SMF  S 

9 

1 

1 

A 

E 

Cl 

C2 

C3 

C4 

10 

LI 

0 

0 

1 

1 

0 

1 

1 

SMF  6 

11 

1 

1 

A 

E 

Cl 

C2 

C3 

C4 

12 

L2 

0 

0 

1 

1 

0 

1 

1 

SMF  7 

13 

U 

1 

A 

E 

Cl 

C2 

C3 

C4 

14 

TEA 

0 

0 

1 

1 

0 

1 

1 

SMF  8 

15 

R 

1 

A 

E 

Cl 

C2 

C3 

C4 

L1-L3:  channel  number,  least  significant  bit  in  LI 


Channel 

Initial 

Second 

Third 

Sixth 


u  u 

0  1 

1  0 
1  1 

i  6 


u 

0 

0 

0 

1 


R: 

A.  E,  C1-C4: 
N1-N4; 


Reserved  for  future  use  *  sec  co  0. 

As  In  Figure  2/H.221. 

Used  for  mulciframe  numbering  as  described  in  section  2.2. 
while  numbering  is  inactive. 


Sec  Co  0 


N4 

N3 

M2 

Ml 

Multiframe  number;  0 

0 

0 

0 

0  (or  numbering  inactive) 

1 

0 

0 

0 

1 

2 

0 

0 

1 

0 

15 


1 


1 


N5;  Indicates  whether  multiframe  numbering  is  active  (N5-1)  or  inactive  (N5-0) . 
TEA:  The  terminal  equipment  alarm  is  set  to  I  in  the  outgoing  signal  while  an 
internal  terminal  equipment  fault  exists  such  that  it  cannot  receive  and 
act  on  Che  incoming  signal.  Otherwise  it  is  sec  to  0. 


FIGURE  3/H.221 

Assignment  of  bits  1-8  of  the  service  channgL  in 
each  frame  in  a  mulciframe 
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2.3  Loss  and  recovery  of  frame  alignment 

Fraa*  alignaent;  is  defined  to  have  been  lost  when  three  consecutive 
frame  alignment  words  nave  been  received  with  an  error. 

Frame  alignment  is  defined  to  have  been  recovered  when  the  following 
sequence  is  detected: 

for  the  first  time,  the  presence  of  the  correct  first  seven  bits 
of  the  frame  alignment  word; 

the  eighth  bit  of  the  frame  alignment  word  in  the  following  frame 
is  detected  by  verifying  that  bit  2  is  a  1; 

for  the  second  time,  the  presence  of  the  correct  first  seven  bits 
of  the  frame  alignment  word  in  the  next  frame. 

If  frame  alignment  is  achieved  but  multiframe  alignment  cannot  be 
achieved,  then  frame  alignment  should  be  sought  at  another  position. 

When  the  frame  alignment  is  lost,  A*bit  of  the  next  odd  frame  is  set  to 
1  in  the  transmit  direction. 

2.4  Loss  and  recovery  of  multiframe  alignment 

Multiframe  alignment  is  needed  to  number  and  synchronize  two  or  more 
channels,  and  possibly  also  for  encryption.  Terminals  such  as  chose  having  only 
single -channel  capabilities  which  have  no  use  for  the  multiframe  structure  must 
transmit  the  multiframe  structure,  but  need  not  check  for  multiframe  alignment 
on  the  incoming  signal:  they  may  transmit  outgoing  A-0  when  frame  alignment  is 
recovered.  (Note  •  such  a  terminal  cannot  transmit  TEA  •  see  Figure  3/H.221). 

After  multiframe  alignment  has  been  validated  the  ocher  fiinctions 
represented  by  bit  1  of  the  Service  Channel  can  be  used.  When  multiframe 
alignment  of  the  distant  terminal  has  been  signalled  (A*^)  received)  the  distant 
terminal  is  expected  to  have  validated  BAS  codes  and  to  -be  able  to  interpret  BAS 
codes . 


Multiframe  alignment  is  defined  to  have  been  lost  when  three 
consecutive  multiframe  alignment  signals  have  been  received  with  an  error.  It  is 
defined  to  have  been  recovered  when  the  multiframe  alignment  signal  has  been 
received  with  no  error  in  the  next  multiframe.  When  multiframe  alignment  is 
lost,  even  when  an  unframed  mode  is  received,  the  A-bit  of  the  next  odd  frame  is 
sec  to  1  in  Che  transmit  direction.  It  is  reset  to  0  when  multiframe  alignment 
is  regained.  It  is  reset  in  additional  channels  when  multiframe  alignment  and 
synchronism  with  the  initial  channel  is  regained. 

2.5  Procedure  to  recover  octet  timing  from  frame  allmment 

When  the  network  does  not  provide  octet  timing,  the  terminal  may 
recover  octet  timing  in  the  receive  direction  from  bit  timing  and  from  the  frame 
alignment.  The  octet  timing  in  the  transmit  direction  may  be  derived  from  the 
network  bit  timing  and  an  internal  octet  timing. 
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2.5.1  G^naral  rul« 

The  receive  octet  timing  is  normally  determined  £rom  the  FAS  position. 
But  at  the  start  of  the  call  and  before  the  frame  alignment  is  gained,  the 
receive  octet  timing  may  be  taken  to  be  the  same  as  the  internal  transmit  octet 
timing.  As  soon  as  a  first  frame  alignment  is  gained,  the  receive  octet  timing 
is  initialized  at  the  new  bit  position,  but  it  is  not  yet  validated.  It  will  be 
validated  only  when  frame  alignment  is  not  lost  during  the  next  16  frames. 

2.5.2  Earttcular  giata 

a)  When,  at  the  initiation  of  a  call,  the  terminal  is  in  a  forced 
reception  mode,  or  when  the  frame  alignment  has  not  yet  been 
gained,  the  terminal  may  temporarily  use  the  transmit  octet 
timing . 

b)  When  frame  alignment  is  lost  after  being  gained,  the  receive 
octet  timing  should  not  change  until  frame  alignment  is 
recovered. 

c)  As  soon  as  frame  and  multiframe  alignment  have  been  gained  once, 
the  octet  timing  is  considered  as  valid  for  the  rest  of  the  call, 
unless  frame  alignment  is  lost  and  a  new  frame  alignment  is 
gained  at  another  bit  position. 

d)  When  the  terminal  switches  from  a  framed  mode  to  an  unframed  mode 
(by  means  of  the  BAS) ,  the  octet  timing  previously  gained  must  be 
kept. 

e)  When  a  new  frame  alignment  is  gained  on  a  new  position,  different 
from  that  previously  validated,  the  receive  octet  timing  is 
reinitialized  to  the  new  position  but  not  yet  validated  and  the 
previous  bit  position  is  stored.  If  no  loss  of  frame  alignment 
occurs  in  the  next  16  frames,  the  new  position  is  validated, 
otherwise  the  stored  old  bit  position  is  reutllized. 

2.5.3  Search  for  frame  alignment  signal  (FASl 

Two  methods  may  be  used:  sequential  or  parallel.  In  the  sequential 
method,  each  of  the  eight  possible  bit  positions  for  the  FAS  is  tried.  When  FAS 
is  lost  after  being  validated,  the  search  must  resume  starting  from  the 
previously  validated  bit  position.  In  the  parallel  method,  a  sliding  window, 
shifting  one  bit  for  each  bit  period,  may  be  used.  In  that  case,  when  frame 
alignment  is  lost,  the  search  must  resume  starting  from  the  bit  position  next  to 
the  previously  validated  one. 

2.6  Description  of  the  CRCA  procedure 

In  order  to  provide  an  end-to-end  quality  monitoring  of  the  connection, 
a  4-bit  cyclic  redundancy  check  (CRC4)  procedure  may  be  used  and  the  four  bits 
Cl,  C2,  C3  and  C4  computed  at  the  source  location  are  inserted  in  bit  positions 
5  to  8  of  the  odd  frames.  In  addition,  bit  4  of  the  odd  frames,  the  "E-bit",  is 
used  to  transmit  an  indication  as  to  whether  the  most  recent  CRC  block,  received 
in  the  incoming  direction,  contained  errors  or  not. 
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When  the  CRC4  procedure  is  not  xised,  bit  E  shall  be  set  to  0,  and  bits 
Cl,  C2,  C3  and  C4  shall  be  set  to  1  by  the  transmitter.  Provisionally,  the 
receiver  loay  disable  reporting  of  CRC  errors  after  receiving  eight  consecutive 
CRCs  set  to  all  Is,  and  It  may  enable  reporting  of  CRC  errors  after  receiving 
two  consecutive  CRCs  each  containing  a  0  bit. 

2.6.1  Computation  of  the  CRC4  bits 

The  CRC4  bits  Cl,  C2  C3  and  C4  are  computed  for  each  B/H0/H11/H12 
channel^,  for  a  block  made  of  two  frames:  one  even  frame  (containing  the  first 
seven  bits  of  FAW)  followed  by  one  odd  frame  (containing  the  eighth  bit  of  FAU) . 
The  CRC4  block  size  la  then  160/960/3840/4800  octets  for  a  B/H0/H11/H12 
channel^  and  the  computation  Is  performed  SO  times  per  second. 

Note  •  This  Is  still  valid  for  the  case  of  HO/Hll  In  restricted  networks,  the 
stuffed  bits  being  Included  In  Che  computation.  For  restricted  B,  see  Annex  2. 

2. 6. 1.1  Multiplication-division  process 


A  given  Cl -04  word  located  in  block  N  is  the  reowinder  after 
multiplication  by  and  Chen  division  (modulo  2)  by  the  generator  polynomial 
x^  -f  X  4-  1  of  the  polynomial  representation  of  block  (N-1)  . 


When  representing  contents  of  a  block  as  a  polynomial,  the  first  bit  In 
the  block  should  be  taken  as  being  the  most  significant  bit.  Similarly  Cl  is 
defined  to  be  the  most  significant  bit  of  the  remainder  and  C4  the  least 
significant  bit  of  the  remainder. 


This  process  can  be  realized  with  a  four- stage  register  and  two 
exclusive-ORs. 

2. 6. 2.1  Encoding  procedure 

I)  The  CRC  bit  positions  In  the  odd  frame  are  Initially  sec  at  zero, 
i.e.,  C1-C2-C3-C4-0. 

II)  The  block  is  the  acted  upon  by  the  multiplication-division 
process  referred  to  above  In  2. 6. 1.1. 

III)  The  remainder  resulting  from  the  multiplication-division  process 
Is  scored  ready  for  Insertion  Into  the  respective  CRC  locations 
of  Che  next  odd  frame. 


Note  -  These  CRC  bits  do  not  affect  the  computation  of  the  CRC  bits  of  the  next 
block,  since  the  corresponding  locations  are  sec  at  zero  before  the 
computation. 

2 . 6 . 1 . 3  Decoding  procedure 

i)  A  received  block  is  acted  upon  by  the  multiplication-division 

process,  referred  to  above  In  2. 6. 1.1,  after  having  Its  CRC  bits 
extracted  and  replaced  by  zeros. 


^  If  the  transfer  race  Is  such  chat  a  part  of  any  H0/H11/H12  channel  Is 

unoccupied,  Chen  the  computation  Is  made  only  for  chat  part  covered  by  the 
transfer  race. 
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ii)  Th«  remainder  resulting  from  this  multiplication-division  process 
is  then  stored  and  subsequently  compared  on  a  bit-by-bit  basis 
with  the  CRC  bits  received  in  the  next  block. 

iii)  If  Che  decoded  calculated  remainder  exactly  corresponds  to  Che 
CRC  bits  sent  from  the  encoder,  it  is  assumed  chat  the  checked 
block  is  error -free. 

2.6.2  Consaouent  actions 

2 . 6 . 2 . 1  Action  on  bit  E 

Bit  E  of  block  N  is  set  to  1  in  the  transmitting  direction  if  bits  Cl- 
C4  detected  in  the  most  recent  block  in  the  opposite  direction  have  been  found 
in  error  <ac  least  one  bit  in  error).  In  the  opposite  case  it  is  sec  to  zero. 

2. 6. 2. 2  Monitoring  for  incorrect  frame  alignment  (see  note  below) 

In  the  case  of  a  long  simulation  of  the  FAW,  the  CRC4  Information  can 
be  used  to  re- invite  a  search  for  frame  alignment.  For  such  a  purpose  it  is 
possible  CO  count  the  number  of  CRC  blocks  in  error  within  two  seconds  (100 
blocks)  and  to  compare  this  number  with  89.  If  the  number  of  CRC  blocks  in  error 
is  greater  chan  or  equal  to  89,  a  search  for  frame  alignment  should  be  re¬ 
initiated. 

These  values  100  and  89  have  been  chosen  in  order  chat: 

•  For  a  random  transmission  error  rate  of  10*^,  the  probability  of 
incorrectly  re- initiating  a  search  for  frame  alignment,  because 
of  89  or  more  blocks  in  error,  should  be  less  chan  10*^. 

-  In  case  of  simulation  of  frame  alignment,  the  probability  of  not 
re- initiating  a  search  of  frame  alignment  after  a  two-second 
period  should  be  leas  chan  2.5X. 

Note  -  Values  in  this  and  the  next  section  exemplify  the  ease  of  a  64  kbit/s 
channel.  For  HO,  Hll  or  H12  channels  the  details  will  differ  but  the  principles 
are  still  applicable. 

2. 6. 2. 3  Monitoring  for  error  performance 

The  quality  of  the  64  kbit/s  connection  can  be  monitored  by  counting 
the  number  of  CRC  blocks  in  error  within  a  period  of  one  second  (50  blocks).  For 
instance,  a  good  evaluation  of  the  proportion  of  seconds  without  errors  as 
defined  in  CCITT  Recommendation  G.821  can  be  provided. 

For  information  purposes,  the  following  proportions  of  CRC  block  in 
error  can  be  computed  for  randomly  distributed  errors  of  error  rate 


Pe 

10-3 

10*^ 

10*5 

o 

1 

10*7 

Percentage  of  CRC 
blocks  in  error 

70Z 

12X 

1.2X 

0.12X 

0.012X 

By  counting  the  received  E  bits,  it  is  possible  to  monitor  the  quality 
of  the  connection  in  the  opposite  direction. 
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2.7  Svnchronlzacion  of  mulciole  conneccions 

SoM  audiovisual  terminals  will  be  able  to  communicate  over  multiple  B 
or  HO  conneccions  (see  note  below).  In  this  case,  a  single  B  or  HO  initial 
connection  is  established,  the  possibility  for  more  connections  is  determined 
from  the  transfer  rate  capability  BAS  of  Annex  1  and  the  additional  connections 
are  then  established  and  synchronized  by  the  terminal  using  the  multiframe 
structure . 

Note  •  A  connection  is  an  Individual  call  between  the  terminals.  A  channel  is 
the  transmission  in  one  direction  over  the  connection. 

2.7.1  Multiple  B  connections 

FAS  and  BAS  are  transmitted  in  each  B>channel. 

FAS  operation  is  as  follows: 

multiframe  numbering  is  used  to  determine  relative  transmission 
delay  between  B-channels  as  described  in  2.2; 

the  channel  numbers  are  transmitted  as  described  in  2.2  with  the 
channel  of  the  initial  connection  being  numbered  1  and  there 
being  up  to  five  additional  connections; 

the  outgoing  A>bit  is  set  to  1  in  the  additional  B>channel  of  the 
same  connection  whenever  the  received  additional  channel  is  not 
synchronized  the  initial  channel; 

when  receive  synchronization  is  achieved  between  the  initial  and 
additional  channels  by  introducing  delay  to  align  their 
respective  multiframe  signals,  the  transmitted  A-bit  is  set  to 
0; 

the  E'bit  for  each  additional  B-channel  is  transmitted  in  the 
additional  B'channel  in  the  same  connection,  because  it  relates 
to  a  physical  condition  of  the  transmission  path. 

The  BAS  operation  in  additional  connections  is  restricted  to  the 
transmission  of  the  additional  channel  number  (thus  the  channel  numbering  must 
be  sent  both  in  BAS  according  to  Annex  1  and  in  the  FAS  as  in  section  2.2). 

The  distant  terminal,  upon  receiving  the  A-bit  set  to  zero  with  respect 
to  sequentially  numbered  channels,  can  add  their  capacity  to  the  initial 
connection  by  sending  the  transfer  rate  BAS  in  Annex  1.  The  order  of  the  bits 
transmitted  in  the  channels  is  in  accordance  with  the  examples  given  in 
Figure  4/H.221. 

2.7.2  Multiple  HO  connections 

FAS  and  BAS  are  transmitted  in  the  first  time- slot  of  each  HO. 

FAS  operation  is  as  in  2.7.1  except  that  the  channel  number  is  used  to 
order  the  six  octets  received  each  125  microseconds  with  respect  to  the  six 
octet  groups  received  in  other  channels. 

The  BAS  operation  in  additional  channels  is  as  specified  in  2.7.1. 
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3.  Bit-raf  allocation  signal 

3.1  Encoding  of  the  BAS 

Tha  blc>race  allocaclon  signal  (BAS)  occupies  bits  9-16  of  the  Service 
Channel  in  every  frame.  An  eight  bit  BAS  coda  (bQ,  b^,  b2,  b3,  b4,  bs,  bg,  b7) 
is  complemented  by. eight  error  correction  bits  (pQ.  Pl,  P2.  P3.  P4.  P5i  P6>  P?) 
to  Implement  a  (16,8)  double  error  correcting  code.  This  error  correcting  code 
is  obtained  by  shortening  the  (17,9)  cyclic  code  with  generator  polynomial: 

g(x)  -  X®  +  +  x2  +  X  +  1 

The  error  correction  bits  are  calculated  as  coefficients  of  the 
remainder  polynomial  in  the  following  equation: 

PQX^  +  p^x®  -  P2x5  +  P3X^  +  P4x3  +  P5x2  +  pgx  +  py 

-  RESg^x)  b^x^^  +  b2x3-3  +  b3X^2  +.  b^x^^.  +  bgx^^  +  bgx^  +  hyx®] 

where  RESg^^^^ [f(x) ]  represents  the  residue  obtained  by  dividing  f(x)  by  g(x)  . 

The  BAS  code  is  sent  in  the  even*nvuabered  frame,  while  the  associated 
error  correction  bits  are  sent  in  the  subsequent  odd*numbered  frame.  The  bits  of 
the  BAS  code  or  the  error  correction  are  transmitted  in  the  following  order  to 
avoid  emulation  of  the  frame  alignment  word: 


position 

Even  frame 

Odd  frame 

9 

bo 

P2 

10 

b3 

PI 

11 

b2 

PO 

12 

bl 

P4 

13 

bs 

P3 

14 

b4 

P5 

15 

b6 

P6 

16 

b7 

P7 

the  receiver  is  in  frame  and  multiframe  alignment,  and 

-  the  FAU  in  the  same  sub-oiultiframe  was  received  with  two  or  fewer 
bits  in  error. 

Otherwise  the  decoded  BAS  value  is  ignored.  When  the  receiver  actually  looses 
frame  alignment,  it  may  be  advisable  to  undo  any  changes  cavisad  by  the  three 
previously  decoded  values  as  they  may  well  have  been  erroneous  even  after 
correction. 

3 . 2  Values  of  the  BAS 

The  encoding  of  BAS  is  made  according  to  a  hierarchical  attribute 
method.  This  consists  of  attribute  class  (8  classes),  attribute  family 
(8  families),  attribute  (8  attributes)  and  value  (32  values).  The  first  three 
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bits  of  an  actributa  represent  its  number  describing  the  general  command  or 
capability,  and  the  other  five  bits  identify  the  "value”  •  the  specific  command 
or  capability. 

The  following  actributes  are  defined  in  the  Class  (000)  and 
Family  (000) : 


Attribute 

Significance 

000 

Audio  Coding  Command 

001 

Transfer  Race  Command 

010 

Video  and  ocher  Command 

Oil 

Data  Command 

100 

Terminal  Capability  1 

101 

Terminal  Capability  2 

110 

Reserved 

111 

Escape  Codes 

The  values  of  these  attributes  are  listed  and  defined  in  Annex  1.  They 
provide  for  the  following  facilities; 

transmission  at  various  total  rates  and  on  single  and  multiple 
channels,  on  clear  channels  and  on  networks  subject  to 
restrictions  to  56  kbit/s  and  its  multiples; 

•  audio  transmission,  digitally  encoded  to  variotis  recommended 
algorithms ; 

•  video  transmission,  digitally  encoded  to  a  recommended  algorithm, 
with  provision  for  future  recommended  improvement; 

•  low'speed  data  (LSO)  within  the  I>channel,  or  TSl  of  a  higher 
rate  initial  channel; 

high-speed  data  (HSD)  in  the  highest- numbered  64  kbit/s  channel 
or  time-slots  (excluding  the  I-channel) ; 

data  transmission  within  a  multilayer  protocol,  either  in  the 
1-channel  (NLP)  or  in  capacity  other  than  the  I-channel  (H-HLP) ; 

an  encryption  control  signal; 

loopback  cowards  the  network  for  maintenance  purposes; 

-  signalling  for  control  and  indications; 

a  message  system  for,  inter  alia,  conveying  information 
concerning  equipment  manufacturer  and  type. 

The  command  BAS  attributes  have  the  following  significance;  on  receipt 
of  a  BAS  command  code  in  one  (even)  frame  and  its  error-correcting  code  in  the 
next  (odd) ,  the  receiver  prepares  to  accept  the  stated  mode  change  beginning 
from  Che  subsequent  (even)  frame;  thus  a  mode  change  can  be  effected  in 
20  milliseconds.  The  command  remains  in  force  until  countermanded  (see 
Recommendation  H.242,  section  12).  The  bit  positions  occupied  by  combinations  of 
BAS  commands  are  exemplified  in  Figure  4(a  to  g) . 
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Th*  eanabilltv  BAS  accribuces  hav«  the  following  significance:  they 
indicate  the  ability  of  a  terainal  to  receive  and  properly  treat  the  various 
types  of  signal.  It  follows  that  having  received  a  sec  of  capability  values  from 
the  remote  terminal  Y,  terminal  X  must  not  transmit  signals  lying  outside  chat 
declared  range. 

Values  [0-7]  of  the  attribute  (111)  are  reserved  for  setting  the  class, 
and  [8-13]  for  setting  the  family;  the  default  value  is  (000)  for  both. 

The  next  eight  attribute  values  of  the  attribute  (111)  are  temporary 
escape  BAS  codes  of  single  byte  extension  (SBE) .  The  last  three  bits  of  the 
temporary  escape  BAS  form  a  pointer  to  one  of  eight  possible  escape  BAS  cables 
of  224  entries  each  (codes  beginning  with  111  are  not  used  in  the  escape  BAS 
cables) .  Then  the  next  received  BAS  indicates  the  specific  entry  in  the  escape 
BAS  cable. 

The  value  (111) [24]  is  Che  capability  marker  (see  Recommendation  H.242, 
section  2)  which  is  followed  by  normal  BAS  codes,  not  by  any  escape  values. 

The  last  seven  attribute  values  of  the  attribute  (111)  are  of  multiple 
byte  extension  (HBE)  and  ace  used  to  send  messages  as  specified  in  the  notes  to 
the  cable  in  Annex  1. 

3.3  Procedures  for  the  use  of  BAS 

The  use  of  BAS  codas  is  specified  in  Recommendation  H.242. 


Bit  Humber  Octet 
7  8  Humber 

1 
2 

8 

9 

16 

17 

18 

80 

FICniRE  4(a)/H.221 

Bit  numbering  and  position  for  14.4  kbic/s  LSD 


1 

2 

1 

8 

9 

; 

16 

n 

WLiM 
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1 

2 

3 

50 

51 

52 

57 

58 

59 

106 

107 

108 

113 

114 

115 

120 

121 

122 

554 

555 

556 

1 

2 

3 

4 

5 

6 

7 

; 

; 

; 

; 

• 

; 

; 

FAS 

50 

51 

52 

53 

54 

55 

56 

57 

58 

59 

60 

61 

62 

63 

; 

; 

; 

; 

; 

BAS 

106 

107 

108 

109 

110 

111 

112 

113 

114 

115 

116 

117 

118 

119 

120 

121 

122 

123 

124 

125 

126 

127 

128 

617 

618 

619 

620 

621 

622 

623 

624 
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Audio  bit  rate 

1 

2 

Bit  NvuBber 
3  4  5 

6 

7 

8 

G.711 

MSB 

•  •  • 

•  •  • 

«  •  • 

•  •  • 

•  •  < 

LSB 

G.722,  64  kb/s 

H 

H 

L 

L 

L 

L 

L 

L 

G.722,  56  kb/a 

H 

H 

L 

L 

L 

L 

L 

G.722,  48  kb/a 

H 

H 

L 

L 

L 

L 

16  kb/a 

A1 

A2 

A  »  audio  bits 
H  -  high-band  audio 
L  -  low- band  audio 

FIGURE  4(d) /H. 221 
Bit  ooaitiona  for  audio 


Initial 

channel 

Additional  channel 

Bit 

1 

2 

3 

■ 

5 

6 

■ 

8 

■ 

f— 

2 

3 

■ 

5 

6 

■ 

‘ 

Al 

A 

A2 

a3 

A4 

AS 

A6 

A 

VI 

V9 

FAS 

V2 

vio 

V3 

V4 

V5 

V6 

V7 

V8 

V16 

FAS 

V121 

V129 

V139 

BAS 

V122 

V131 

BAS 

V130 

V138 

V148 

A 

A 

V759 

V768 

FIGURE  4(a)/H.221 
Bit  DQsicions  for  video  in  2B 
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TS2 

TS3 

TS4 

VI  V8 

V9  V16 

V17  V24 

V25 

V48 

V361 

V384 

V386 

V411 

V409 

vi961.  . 

.  .  V1984 

D8  D9  D16 
D32 


. .01280 


Initial 
B- channel 


2nd  channelled  channel  4ch  channel  5 ch  channel  6 ch  channel 


F  VI 
A  V29 
S 


V7  F  V8 
A 
S 


V14  F  V15 
A 
S 


V21  F  V22 
V42  A 
S 


V28  F  01 
V56  A  09 
S 


V481  0129 
V514  0137 


V2529. 


.V2560  0633. . .0640 
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ANNEX  I 

(CO  Racoovandacion  H.221) 
Dafinltlona  and  tablaa  of  BAS  valuas 


Tha  daflnlciona  of  BAS  valuas  ara  glvan  balow,  and  cha  corraspondlng 
numaclcal  values  are  listed  in  Tables  Al/H.221  and  A2/H.221. 

Audio  eoimnariA  values  (000)  -  for  bit  position  illustrations  see  Figure  4/H.221. 

Abbreviations  "G.711"  and  "G.722"  refer  uo  CCITT 
Reconmendacions . 


Neutral  Neutralized  I •channel,  containing  only  FAS  and  BAS;  all  ocher 

bits  are  to  be  Ignored  at  the  receiver 

Au'off,  U  No  audio  signal,  no  frame  (Mode  10);  all  the  I 'Channel  is 

available  for  use  under  other  commands^ 


Au-off,  F 

A* law,  OU 
A'law,  OF 

H-Uv.  OU 
ft- lav,  OF 

G.722,  ml 
G..722.  m2 
G.722,  m3 
Au>40  Ic 

Au-32  R 


Au-24  k 

Au>16  kbit/s 


No  audio  signal,  FAS  and  BAS  in  use  (Mode  9);  62.4  kbic/s 
available  for  use  under  ocher  commands 

G.711  audio  at  64  kbic/s.  A* law,  no  framing  (Mode  OU)^ 

G.711  audio  at  56  kbit/s,  A*law,  truncated  to  7  bits  in  bits  1-7, 

with  FAS  and  BAS  in  bit  8;  bit  8  is  sec  to  zero  at  the  P(M  audio 
decoder  (Mode  OF) 

G.711  audio  at  64  kbic/s,  u-law,  no  framing  (Mode  OU)^ 

G.711  audio  at  56  kbit/s,  truncated  to  7  bits  in  bits  1-7, 

with  FAS  and  BAS  in  bit  8;  bit  8  is  sec  to  zero  at  the  P(ai  audio 
decoder  (Mode  OF) 

G.722  7  kHz  audio  at  64  kbit/s,  no  framing  (Mode  1)^ 

G.722  7  kHz  audio  at  56  kbit/s.  in  bits  1-7  (Mode  2) 

G.722  7  kHz  audio  at  48  kbit/s,  in  bits  1-6  (Mode  3) 

Reserved  for  audio  at  less  than  48  kbic/s  (for  example  40  kbit/s 

in  bits  1-5) 

Reserved  for  audio  at  less  than  48  kbic/s  (for  example  32  kbit/s 
in  bits  1-4);  the  algorithm  of  "Au-16k"  below  may  be  extended  to 
code  a  wider  speech  bandwidth  at  32  kbic/s  as  a  result  of  further 
studies 

Reserved  for  audio  at  less  chan  48  kbit/s  (for  example  24  kbit/s 
in  bits  1-3) 

Audio  at  16  kbit/s  to  Recommendation  H.200/AV.254  in  bits  1,2 
(Mode  7) 


1  These  attribute  values  designate  unframed  modes.  In  the  receive  direction 
reverting  to  a  framed  mode  can  only  be  achieved  by  reco'.  ering  frame  and 
multiframe  alignment  which  might  cake  up  to  two  multiframes  (320  ms). 
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Au-<16  Ic 

Au- ISO-64/ 
128/192/256 

Au- ISO- 384 

Trangf9r-rat» 

Note  -  If  Che 
capacity,  Che 

64 

2  X  64 

3  to  6  X  64 

384 

2  X  384 

3  CO  3  X  384 

1536 

1920 

128/192/256 

512/768/ 

1152/1472 

Loss-l.c. 

channel  i^2-6 


Reserved  for  audio  ac  less  chan  48  kbic/s  (for  exaople  8  kbic/s 
in  bit  1) 


Audio  to  ISO  standard  ac  64/128/192/256  kbic/s,  in  the  lowest- 
numbered  cime-slocs  (ocher  chan  TSl)  of  an  HO  or  greacer  channel 

Audio  Co  ISO  standard  ac  384  kbic/s  in  cime-slocs  2-7  of  a 
channel  greater  chan  HO. 

command  values  (001) 

transfer- race  command  is  less  chan  the  available  connected 
information  occupies  Che  lowest -numbered  channel(s)/cime-sloc(s} . 

Signal  occupies  one  64  kbic/s  channel 

Signal  occupies  two  64  kbic/s  channels,  with  FAS  and  BAS  in  each  . 

Signal  occupies  three  Co  six  64  kbic/s  channels,  with  FAS  and  BAS 
in  each 

Signal  occupies  384  kbic/s,  with  FAS  and  BAS  in  che  first 
64  kbic/s  time -sloe;  che  effective  channel  may  be  Che  whole  of  an 
HO  channel  or  che  lowest  numbered  cime-slocs  of  an  Hll  or  H12 
channel 

Signal  occupies  cwo  channels  of  384  kbic/s,  wich  FAS  and  BAS  in 
each 

Signal  occupies  chree  co  five  384  kbit/s  channels,  wich  FAS  and 
BAS  in  each 

Signal  occupies  1536  kbic/s,  wich  FAS  and  BAS  in  che  first 
64  kbic/s  cime-sloc.  The  effective  channel  occupies  che  whole  of 
an  Hll  channel  or  che  lowest  numbered  cime-slocs  of  an  H12 
channel 

Signal  occupies  1920  kblC/s,  with  FAS  and  BAS  in  che  first 
64  kbic/s  cime-sloc.  The  effective  channel  occupies  che  whole  of 
an  H12  channel 

Signal  occupies  128/192/256  kbic/s,  wich  FAS  and  BAS  in  che  first 
64  kbic/s  cime-sloc.  The  effective  channel  occupies  che  lowest 
numbered  cime-slocs  of  an  HO  or  larger  channel 

Signal  occupies  4512/768/1152/1472  kblt/s,  with  FAS  and  BAS  in 
Che  first  64  kbic/s  cime-sloc.  The  effective  channel  occupies  che 
lowest  numbered  cime-slocs  of  an  Hll  or  H12  channel 

Designated  "Initial  channel",  especially  used  following  loss  of 
che  channel  previously  so  designated  (see  H.242,  section  7.2.3) 

Numbering  of  additional  channels  -  see  section  2.7.1. 


CCITT\C0MXV\RAPP\R037E1  txs 


-  22  - 

COM  XV-R  37-E 


Video,  encrvoelon.  loop  and  other  commands  (010) 


video-off 

H.261 


vid-tap. (R) 
video- ISO 

AV-ISO 


Freeze -pic. 
Fast -update 
encryp-on 


encryp-off 

Au- loop 
Vid-loop 
Dig- loop 
Loop -off 
SB-HO-comp 


Not-6B-H0 


restrict 


No  video;  video  switched  off 

Video  on,  to  Recotaaendation  H.261:  video  occupies  all  capacity 
not  otherwise  allocated  by  ocher  coaaands;  video  cannot  be 
inserted  in  the  1-channel  when  var-LSD  or  var-MLP  is  in  force; 
exaaples  are  given  in  Figure  4(e) . 

Specifically,  Che  video  rate  in  initial  B- channel  (fraaed)  or  TSI 
is:  62.4  Icbit/s  -  audio  rate  -  (SCO  bic/s  if  ECS  is  ON]  -  (MLP 
rate  if  ON]  -  {LSO  rate  if  ON) 

Reserved  for  video  on.  to  iaproved  recoaaended  algoritha 

Video  on,  CO  ISO  standard:  video  occupies  the  same  capacity  as 
stipulated  above  for  the  case  of  H.261  video 

Coaposite  audio/video  to  ISO  standard:  the  coaposite  signal 
occupies  Che  same  capacity  as  stipulated  above  for  the  case  of 
H.261  video 

Freeze -pic cure  request  (see  Recoaaendation  H.230,  VCF) 

Fast-update  reqtiest  (see  Recoaaendation  H.230,  VCU) 

ECS  Channel  active 

Note:  when  encryption  is  active,  it  applies  to  all  inforaatlon 
bits  in  all  ctu^els  of  the  connection,  except  bits  1-24  of  the 
SC  in  Che  I-channel  and  the  FAS  and  BAS  positions  of  the  ocher 
channels;  use  of  encryption  in  conjunction  with  MLP  is  for 
further  study 

ECS  channel  off 

(loopback  requests  are  intended  for  use  by  aaintenance  staff) 

Audio  loop  request  (see  Recoaaendation  H.230,  LCA) 

Video  loop  request  (see  RecoaBondacion  H.230,  LCV) 

Digital  loop  request  (see  Recoaaendation  H.230,  LCD) 

Loop  off  request  (see  Recoaaendaclon  H.230,  LCO) 

To  provide  for  coispacibility  between  cerainals  connected  to 
single  HO  channel  and  six  B-channel  accesses,  the  least 
significant  bits  of  the  first  16  octets  of  all  time-slots  of  the 
HO  channel,  except  TSI,  are  not  used;  the  HO  cerainal  ausc 
discard  these  bits  froa  the  incoaing  signal  on  receipt  of  this 
code,  and  ausc  sec  the  saae  bits  to  ”1"  in  the  outgoing  signal 

Negates  the  conaand  "6B-H0-coap” 

Note:  used,  for  exaaple,  in  testing 

To  provide  for  operation  on  a  restricted  network,  and  for 
interconnection  between  a  terainal  on  restricted  and  unrestricted 
networks:  on  receipt  of  this  code,  a  terminal  must  treat  the  SC 
as  being  in  bit  7  of  the  I-channel.  and  discard  bit  8  of  every 
other  channel  and/or  time-slot;  in  the  outgoing  direction  these 
bits  are  set  to  "1" 
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derescrlcc  On  receipt  of  this  code,  a  terminal  must  revert  to  "unrestricted 
network"  operation,  creating  the  SC  as  being  in  bit  8  of  the 
I -channel 


LSD /ML?  commands  (Oil)  -  for  bit  position  illustrations  see  Figure  4/H.221. 


these  LSD 

rates 

* 

in  restricted  c 

LSD  off 

LSD  switched  of 

300 

Low- speed 

data 

1200 

Low- speed 

data 

4800 

Low-  speed 

data 

6400 

Low- speed 

data 

8000 

Low- speed 

data 

9600 

Low- speed 

data 

14400 

Low- speed 

data 

16k 

Low- speed 

data 

24k 

Low- speed 

data 

32k 

Low- speed 

data 

40k 

Low- speed 

data 

48k 

Low- speed 

data 

56k 

Low- speed 
case) 

data 

62.4k 

Low- speed  data 
If  ECS  channel 
but  returns  to 

64k 

Low- speed 

data 

var-LSD 

Low- speed  data 

dti(R) 

MLP-off 


under  ocher  fixed-race  commands;  cannot  be  invoked  when  ocher  LSD 
is  on,  or  when  variable-MLF  is  on  (may  also  be  impractical  when 
video  is  on  in  I -channel  alone) 

Exact  var-LSD  rate:  62.4  kbit/s  -  audio  race  -  (800  bit/s  if  ECS 
in  ON)  -  {fixed-MLP  if  ON) 

three  codes  reserved  for  communicating  Che  status  of  Che  data 
terminal  equipment  interfaces 

MLP  off  in  all  channels 
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MLP-4k  MLP  on  «t  4  kblt/s  in  octets  41-80  of  SC 

MLP-6.4k  MLP  on  at  6.4  kbit/s  in  octets  17-80  of  SC;  if  ECS  channel  is  in 

use,  the  data  rate  is  reduced  to  5.6  kbit/s  in  octets  25-80,  but 
returns  to  6.4  kbit/s  if  ECS  channel  is  closed 

var-MLP  MLP  occupying  all  I-channel  capacity  not  allocated  under  other 

fixed- rate  conmands:  cannot  be  invoked  when  other  MLP  is  on.  or 
when  variable-LSD  is  on  (may  also  be  impractical  when  video  is  on 
in  I -channel  alone) ; 

Exact  var-MLP  rate:  62.4  kbit/s  -  audio  rate  -  (800  bit/s  if  ECS 
is  ON)  -  (fixed- LSD  if  ON) 

Audio  eapabllltlas  (100) 

neutral  neutral  capability:  no  change  in  the  current  capabilities  of  the 

terminal 

A- law  capable  of  decoding  audio  to  Recommendation  G.711,  A- lav 

capable  of  decoding  audio  to  Recommendation  G.711,  /i-law 

G.72S-T1  Terminal  Type  1  defined  in  Recommendation  6.725,  section  2 

G.725-T2  Terminal  Type  2  defined  in  Recomnendaclon  G.72S,  section  2 

Au-16  kblt/s  capable  of  decoding  audio,  both  to  Recommendation  H.200/AV.254 
and  Racommendation  6.711 

Au-ISO  capable  of  decoding  audio  to  ISO  standard  at  all  rates  up  to 

384  kblt/s 


(101) 


QCIF  Can  decode  video  to  QCIF  plctxire  format,  but  not  CIF  (see 

Recommendation  H.261)  -  this  coda  must  be  followed  by  one  of  the 
four  MPI  values  below 


CIF  Can  decode  video  to  CIF  and  QCIF  formats  (see  Racommendation 

H.261)  -  this  code  must  be  followed  by  two  MPI  values,  the  first 
applicable  to  QCIF  and  the  other  to  CIF  format.  Minimum  picture 
interval  (MPI)  codes  are  as  follows: 


1/29.97  Can  decode  video,  having  a  minimum  picture  interval  of 

1/29.97  seconds,  to  Recommendation  H.261 

2/29.97  Can  decode  video,  having  a  minimum  picture  interval  of 

2/29.97  seconds,  to  Recommendation  H.261 

3/29.97  Can  decode  video,  having  a  minimum  picture  interval  of 

3/29.97  seconds,  to  Recommendation  H.261 

4/29.97  Can  decode  video,  having  a  minimum  picture  interval  of 

4/29.97  seconds,  to  Recommendation  H.261 

vid-imp(R)  Reserved  for  future  improved  recommended  video  algorithm 
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video 'ISO  Can  decode  video  co  ISO  standard 

AV-ISO  Can  decode  composlce  audlo/vldeo  signal  Co  ISO  standard 

MBE-cap  Can  handle  aultiple-byte  extensions  messages  in  Che  BAS  position, 

chose  beginning  with  codes  in  the  range  (111) [2S<31] ,  in  addition 
CO  ocher  values 

Esc<CF(R}  Reserved  for  capability  to  accept  non*zero  class/family 

escape  codes 


encryp. 


Capable  of  handling  signals  on  the  ECS  channel 


(100) 


64.  384 


Can  accept  signals  only  on  one  64  kbic/s  channel,  one  384  kbit/s 
channel 


2  X  64  Can  accept  signals  on  one  or  two  64  kbic/s  channels,  and 

synchronize  them 


6  X  64  Can  accept  signals  on  one  to  six  64  kbic/s  channels,  and 

synchronize  them 

2  X  384  Can  accept  signals  on  one  or  two  384  kbic/s  channels,  and 

synchronize  them 


3  X  384  Can  accept  signals  on  one  to  five  384  kbic/s  channels,  and 

synchronize  them 

1536/1920  Can  accept  signals  on  a  1536  kblc/s  channel,  a  1920  kbic/s 

channel 

restrict  Can  work  only  at  p  x  56  kbic/s,  race* adapted  co  p  x  64  kbic/s  by 

moving  the  SC  Co  bit  position  7  and  setting  bit  8  to  "one”  in 
every  channel  or  time-slot;  a  constant  "one”,  however,  may  be  set 
in  bit  8  if  it  is  known  by  out-of-band  signalling  prior  to  the 
connection  that  the  restriction  exists;  this  code  has  the  effect 
of  forcing  Che  remote  terminal  to  work  in  Che  p  x  56  kblt/s  mode 
(see  Annex  2) 

6  B-HO-coap  Capable  of  acting  upon  the  corresponding  command 

128/192/256  Capable  of  accepting  the  transfer  rate  specified  by  the 
corresponding  command 

512/768/  Capable  of  accepting  the  transfer  rate  specified  by  the 

1152/1472  corresponding  command 

LSD/MLP  capabilities  (101) 

300  (to  64k)  Can  accept  LSD  at  300  bit/s  (to  64  kbit/s)  in  the  bit  positions 
specified  against  the  corresponding  commands 
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v«r-LSO 

MLP-4k 

MLP-6.4k 

var-MLP 


Can  aecapc  LSD  variable  rata  In  the  bit  positions  specified 
against  the  corresponding  cooaand 

Can  accept  NLP  at  4  kbit/s  in  the  SC 

Can  accept  MLP  at  up  to  6.4  kbit/s  in  the  SC 

Can  accept  ML?  at  up  to  64  kbit/s  in  the  I -channel 


Escape  table  values  (111) 


HSD 


High-speed  data:  a  32-code  table  containing  HSO  capabilities  and 
coonands 


H.230 


Control  and  indications:  a  32-code  table  with  definitions  in 
Recomaendation  H.230 


start-MBE  First  byte  of  (N+2)  octet  BAS  message;  the  message  format  is: 

start-MBE//value  of  H  (maX'-2S5)//M  bytes 

NS-cap  First  byte  of  non-CCITT  capabilities  message;  the  message  format 

is: 


NS-cap//value  of  N  (max-2S5) //country  code*//B*nufacturer 
code*//(N-4)  bytes 

NS-comai  First  byte  of  non-CCITT  command  message;  the  message  format  is: 

NS-conn//value  of  N  (max<»255) //country  code*//®*n“f*cturer 
code*//(N-4)  bytes 

cap-mark  Capability  marker  •  the  first  item  in  a  capability  set  -  see 

Recommendation  H.242,  section  2 

Oata-apps  Applications  within  LSO/HSD  channels:  a  32-code  table  -  see 

Table  A3/H.221. 


Note  1  -  The  value  of  N  is  coded  by  its  binary  representation. 

Note  2  -  The  most  significant  bit  of  each  MBE  message  byte  is  transmitted  as  the 
"bo"  bit  of  BAS. 

HSD/H-MLP  capabilities  (111)10000- (101) 

64k  to  lS36k  Can  accept  HSD  at  the  specified  rate  in  the  bit  positions 
specified  against  the  corresponding  commands 

HSD-other  Reserved  for  other  HSD  rates 

var-HSD  Can  accept  HSD  variable  rate  in  the  bit  positions  specified 

against  the  corresponding  command 


*  Country  cods  consists  of  two  bytes,  the  first  being  according  to 

Recommendation  T.3S;  the  second  byte  and  the  terminal  manufacturer  code  of 
two  bytes  are  assigned  nationally 
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H*MU*62.4k  Can  accept  MLP  at  62.4  kbit/s  in  the  bit  positions  specified 
against  the  corresponding  command 


H-MLP-r  Can  accept  MLP  at  r-64/128/192/256/320/384  kblt/s  in  the  bit 

positions  specified  against  the  corresponding  command 

var-H>MLP  Reserved  for  capability  to  accept  H-MLP  variable  rate  in  the  bit 

positions  specified  against  the  corresponding  command 


HSD/H-MLP  commands  (111)10000- (Oil) 


t^ote  •  In  the  cases  of  multiple  channels,  the  term  "hi^est-numbered  time-slot* 
refers  to  the  highest-numbered  channel. 


HSD-off 


HSD  switched  off;  FAS  and  BAS  restored  in  additional  channels 


64k 


HSD  on,  in  highest  numbered  channel/time-slot;  FAS  and  BAS  are 
removed  in  the  case  of  multiple  B- channels 


128/192/2S6k  HSD  on  in  highest-numbered  time- slots  of  an  HO  or  greater 
channel 

320k  HSD  on  in  highest-numbered  time-slots  of  an  HO  or  greater 

channel 


384k 


HSD -other 


HSD  on  in  highest -numbered  HO  channel,  or  highest -ntimbered  time- 
slots  of  a  greater  channel;  FAS  and  BAS  are  removed  in  the  case 
of  multipIe-HO  channels 

Reserved  for  other  HSD  rates 


var-HSD  Reserved  for  high-speed  data  occupying  all  capacity,  other  than 

in  the  I -channel,  not  allocated  under  other  coonands:  cannot  be 
invoked  when  other  HSD  is  on,  or  when  var-H-MLP  is  on  (may  also 
be  impractical  when  video  is  on,  the  latter  then  being  confined 
to  the  I-channel) 

H-MLP-off  H-MLF  switched  off  (this  does  not  affect  I-channel  MLP) 


H-MLP-62.4 

H-MLP-64k 
H-MLP-128k 
H-MLP-192k 
H-MLP-256k 
H-MLP- 320k 
H-MLP- 384k 


H-MLP  on  at  62.4  kbit/s,  occupying  second  64  kbit/s  channel 
except  FAS  and  BAS  positions 


H-MLP  on  at  64/128/192/256/320  kbit/s  in  the  lowest -numbered 
time-slots  (other  than  TSl)  of  an  HO  or  greater  channel 

H-MLP  on  at  384  kbit/s  in  time-slots  2-7  of  a  greater  channel 
than  HO 


var-H-MLP  Reserved  for  MLP  occupying  all  capacity,  other  than  in  the 

I-channel,  not  allocated  under  other  commands:  cannot  be 
invoked  when  ocher  MLP  is  on,  or  when  var-HSD  is  on 

Note  -  When  the  "restrict"  command  is  In  force  the  least  significant  bit  of  all 
octets  covered  by  the  HSD  and  H-MLP  conunands  is  set  to  "1" ,  so  the  effective 
data  race  is  less  chan  that  indicated  by  the  command. 
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Apallcatlona  within 

ISO-SP  basalltM  on 
LSD 

ISO-SF  baseline  on 
HSD 

ISO-SP  spatial 
ISO-SP  progressive 

ISO-SP  arithaetlc. 

Graphics  cursor 
Group  3  Fax 
Group  4  Fax 
V.120  LSD 

V.120  HSD 

Apolicaciona  within 

ISO-SF  on  in  LSD 

ISO-SP  on  in  HSD 

Cursor  data  on  in 
LSD 

Fax  on  in  LSD 
Fax  on  In  HSD 
V.120  LSD 
V.120  HSD 
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LSD/HSD  channels  -  caoabtlittes  (111)10010- (101) 

Can  accept  ISO-still  picture  baseline  mode  on  specified  LSO 
race 

Can  accept  ISO-still  picture  baseline  mode  on  specified  HSD 
rate 

Can  accept  ISO-still  picture  baseline  -  and  spatial  mode 

Can  accept  ISO- still  picture  baseline  -  and  progressive 
mode 

Can  accept  ISO- still  picture  baseline  -  and  arithmetic 
mode 

Can  handle  graphics  cursor  data 
Can  accept  group  3  Fax 
Can  accept  group  4  Fax 

Can  accept  V.120  terminal  adaptation  within  an  LSD 
channels 

Can  accept  V.120  terminal  adaptation  within  an  HSD 
channel 

LSD/HSD  channels  -  commands  (111)10010- (Oil) 

ISO- still  picture  switched  on  in  specified  LSD 
ISO- still  picture  switched  on  in  specified  HSD 
Cursor  data  switched  on  in  specified  LSD 

Fax  switched  on  in  specified  LSD 
Fax  switched  on  in  specified  HSD 
V.120  switched  on  in  specified  LSD 
V.120  switched  on  in  specified  HSD 
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TABLE  Al/H.221 
BAS  numerical  values 


The  coliuon  header  gives  the  attribute  designation  as  bits  (bo,bi,b2); 
the  left-hand  colunn  gives  the  decimal  value  of  bits  [b3,b4,,b5,bg,b7] ;  for 
example,  "channel  #6"  has  the  value  (001) [10110] .  All  unassigned  values  are 
reserved,  as  are  values  marked  (R) . 


(000) 

(001) 

(010) 

(Oil) 

(100) 

(101) 

(111) 

audio 

trans - 

other 

LSD/MLP 

audio/ 

data/ 

escape 

command 

fer 

command 

command 

transfer¬ 

video 

rate 

rate 

capabl- 

com¬ 

capability  lity 

mand 

[0] 

neutral 

64 

video  off 

LSD  off 

neutral 

var-LSD 

Cl] 

2x64 

H.261 

300 

A- law 

300 

[2] 

3x64 

vld-imp(R) 

1200 

M-law 

1200 

[3] 

4x64 

video-ISO 

4800 

G.725-T1 

4800 

[4] 

A- law,  OU 

5x64 

AV-ISO 

6400 

G.725-T2 

6400 

C5] 

p-law,  OU 

6x64 

8000 

Au-16kbit/s8000 

[6] 

G.722,  ml 

384 

enctyp-on 

9600 

Au-ISO 

9600 

[7] 

AU-off,  U 

2x384 

encryp-off 

14400 

14400 

[8] 

Note  1 

3x384 

16k 

128 

16k 

(9] 

Note  1 

4x384 

24k 

192 

24k 

[10] 

5x384 

32k 

256 

32k 

cm 

1536 

40k 

40k 

C12] 

1920 

48k 

512 

48k 

C13] 

Au-ISO-64 

128 

56k 

768 

56k 

CU] 

Au- ISO- 128 

192 

62.4k 

62.4k 

CIS] 

Au- ISO- 192 

256 

64k 

1152 

64k 

[16] 

Au-ISO-256 

freeze-pic 

MLP -off 

IB 

MLP-4k 

HSD 

C17] 

Au- ISO- 384 

loss  i.c. 

fast-update 

MLP-4k 

2B 

MLP-6.4k 

H.230 

[18] 

A- law, OF 

chan.f!>2 

Au- loop 

MLF-6.4k 

3B 

var-MLP 

Data-apps 

[19] 

M- law, OF 

chan.  #3 

Vid-loop 

var-MLP 

4B 

(R-SBE) 

[20] 

chan. #4  Dig- loop 

5B 

QCIF 

(R-SBE) 

[21] 

chan. #5  Loop-off 

dti-l(R) 

6B 

CIF 

(R-SBE) 

[22] 

chan.ff(6 

dti-2(R) 

restrict 

1/29.97 

(R-SBE) 

[23] 

512 

dtl-3(R) 

6B-H0-comp 

2/29.97 

(R-SBE) 

[24] 

G.722,ffl2(Note2)768 

HO 

3/29.97 

cap -mark 

[25] 

G.722,m3(Mote2) 

6B-H0-contp 

2H0 

4/29.97 

start -MBE 

[26] 

(Au-40k) 

1152 

No-comp  6B-1 

HO 

3H0 

V-imp(R) 

[27] 

(Au-32k) 

restrict 

4H0 

video- ISO 

[28] 

(Au-24k) 

derestrict 

5H0 

AV-ISO 

[29] 

Au-16kblt/s 

1472 

1472 

esc-CF(R) 

[30] 

(Au-<16k) 

Hll 

encryp. 

ns -cap 

[31] 

Au-off,  F 

var-LSD 

H12 

MBE-cap 

ns -comm 

_I  -  These  codes  are  listed  in  Recommendation  G.725  with  reference  to  an 

"application  channel”;  such  a  channel  has  not  been  defined,  the  concept  having 
been  superseded  by  that  of  LSD/MLP;  therefore  these  codes  should  not  be  used. 

Note  2  -  These  codes  are  listed  in  Recommendation  G.72S  with  reference  to 
"data";  however,  the  nature  of  such  data  (video,  LSD,  MLP,  ECS)  must  be 
specified  by  further  commands  (001),  (010),  (011). 
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TABLE  A2/H.221 
HSD/H-MLP  numarleal  values 


Escape  tabla  reached  bv  BAS  (111)  f  1.61 

The  column  header  gives  the  actribuce  designation  as  bits  (bo,bi,b2) 
Che  left-hand  column  gives  the  decimal  value  of  bits  (b3,b4,b5,b6,b7] .  All 
unassigned  values  are  reserved,  as  are  values  marked  (R) . 


capabilities  (101) 

enmmanda  (Oil) 

[0] 

HSD-off 

[1] 

var-HSD(R) 

var-HSD(R) 

[2] 

H-MLP-62.A 

H-MLP-62.4 

[3] 

H-HLP-64 

H-MLP-64 

[4] 

H-MLP-128 

H-MLP-128 

[5] 

H-MLP-192 

H-MLP-192 

[6] 

H-MLP-256 

H-MLP-256 

[7] 

H-MLP-320 

H-MLP-320 

[8] 

H-MLP-384 

H-MLP-384 

[9] 

[10] 

[11] 

[12] 

var-H-MLP(R) 

[13] 

var'H-MLP(R) 

[U] 

H-MLP-off 

[15] 

[16] 


V  —  -  J 

[17] 

64k 

64k 

[18] 

128k 

128k 

[19] 

192k 

192k 

[20] 

2S6k 

2S6k 

[21] 

320k 

320k 

[22] 

384k 

384k 

[23] 

512k<R) 

512k(R) 

[24] 

768k(R) 

768k(R) 

[25] 

1152k(R) 

1152k(R) 

[26] 

[27] 

[28] 

[29] 

[30] 

[31] 

1536k(R} 

1536k(R) 
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TABLE  A3/H.221 


The  coIxuBxi  header  gives  the  attribute  designation  as  bits  (b0ibi,b2) 
the  left-hand  column  gives  the  decimal  value  of  bits  [b3,b4,b5,b5,b7] .  All 
assigned  values  are  reserved,  as  are  values  marked  (R) . 


capabilities  (101) 

commands  (Oil) 

[0] 

ISO-SP  baseline  on  LSD 

ISO-SP  on  in  LSD 

(11 

ISO-SP  baseline  on  HSD 

ISO-SP  on  in  HSD 

[2] 

ISO-SP  spatial 

[3] 

ISO-SP  progressive 

[4] 

[5] 

[6] 

[71 

[8] 

[9] 

ISO-SP  arithmetic 

[10] 

[IIJ 

[12] 

[13] 

[14] 

[15] 

Graphics  cursor 

Cursor  data  on  in 

[U] 

Group  3  Fax 

Fax  on  in  LSD 

[17] 

[18] 
[19] 

Group  4  Fax 

Fax  on  in  HSD 

[20] 

V.120  LSD 

V.120  LSD 

[21] 

[22] 

V.120  HSD 

V.120  HSD 

[23] 

[24] 

[25] 

[26] 

[27] 

[28] 

[29] 

[30] 

[31] 
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ANNEX  2 

(CO  Recomaondaclon  H.221} 


Bit  number 


1 

2 

3 

4 

5 

6 

7  (SC) 

8 

1 

1 

s 

S 

s 

s 

S 

S 

FAS 

1 

u 

u 

u 

u 

u 

u 

1 

8 

b 

b 

b 

b 

b 

b 

1 

9 

- 

- 

- 

- 

- 

- 

BAS 

1 

* 

C 

C 

C 

C 

C 

C 

1 

16 

h 

h 

h 

h 

h 

h 

1 

17 

a 

a 

a 

a 

a 

a 

(ECS) 

1 

. 

n 

n 

n 

n 

n 

n 

1 

24 

n 

n 

n 

n 

n 

n 

1 

25 

e 

e 

e 

e 

e 

e 

1 

* 

1 

1 

1 

1 

1 

1 

1 

# 

y/ 

* 

# 

# 

# 

# 

1 

1 

2 

3 

4 

5 

6 

7 

1 

80 

OcCec  Number 


Note  •  Cl,  C2,  C3  end  C4  In  Che  FAS  ere  cootpuced  for  che  160  sepcecs,  or 
1120  bits. 


The  cransmlccer  fills  che  elghch  sub-channel  with  ”1”,  while  che 
receiver  searches  FAS  at  every  sub-channel. 


Since  che  interworking  bit  cate  becomes  56  kbit/s,  che  transmission 
modes  using  more  than  56  kblc/s  are  forbidden  (receivers  ignore  these  command 
BAS  codes).  Facilities  using  che  original  seventh  sub-channel  move  co  che  sixth 
sub -channel. 


those  in  Annex  1. 


-  che  following  are  applicable  instead  of 


Neucral  Neutralised  I -channel,  containing  only  FAS  and  BAS;  all  ocher 

bits  are  co  be  ignored  at  che  receiver 

Au-off,  U  No  atidio  signal,  no  framing;  bits  1-7  of  che  I-channel  are 

available 

Au-off,  Z  No  audio  signal,  FAS  and  BAS  in  use;  54.4  kbit/s  available  for 

use  under  ocher  commands 

A- law,  U7  G.711  audio  at  56  kbic/s.  A- law  truncated  to  7  bits,  no  framing 

(Mode  OU) 
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A* law. 

F6 

/i-law. 

U7 

M-law, 

F6 

G.722, 

U8 

G.722, 

U7 

G.722, 

F6 

Au-16 

kbit/s 

G.71I  audio  ac  48  kbic/s,  A- lav  truncated  to  6  bits,  with  FAS  and 
BAS  in  bit  7 

G.711  audio  at  56  kbit/s,  m*1*v  truncated  to  7  bits,  no  fraaing 
(Mode  OU) 

G.711  audio  at  48  kbit/s,  |t-law  truncated  to  6  bits,  with  FAS  and 
BAS  in  bit  7 

not  possible  to  transmit  8  bits  per  octet 

G.722  7kHz  audio  in  bits  1*7,  56  kbit/s  (unframed) 

G.722  7  kHz  audio  at  48  kbit/s,  in  bits  1*6  (Mode  3) 

Audio  at  16  kbit/s  to  Recommendation  H.200/AV.254  in  bits  1,2 
(Mode  7) 


[other] 


All  other  values  reserved 


The  following  (000)  values  are  assigned  maintaining  the  same  number  of 
audio  bits  per  octet  between  the  64  kbit/s  and  56  kbit/s  environments: 


[0] 

Neutral 

[6] 

not  oossible 

[7] 

AU'Off,  II 

[18] 

A- law,  U7 

[19] 

/i-law,  U7 

[20] 

A- law,  F6 

[21] 

/i-law,  F6 

[24] 

G.722,  U7 

[25] 

G.722,  F6 

[29] 

Au-16  kbit/s 

[31] 

Au-off,  F 
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2.  R«cq— ndation  H.230 

ntAME- SYNCHRONOUS  CONTROL  AND  INDICATION  SIGNALS 
FOR  AUDIOVISUAL  SYSTEMS 

££l£[miX& 

1 .  Incroduction 

2 .  Frocediires 

3.  D«flnitlons  of  C&I  syabols 

4.  Roqulronants  for  C&I 


1.  InKv4ucslon 

Digital  audiovisual  sarvlcas  ara  provldad  by  a  transmission  systam  in 
which  tha  ralavant  signals  ara  multiplaxad  onto  a  digital  path.  In  addition  to 
tha  audio,  vidao,  uaar  data  and  telematic  information,  these  signals  include 
information  for  tha  proper  functioning  of  tha  system.  The  additional  information 
has  bean  named  "control  and  indication"  (C&I)  to  reflect  the  fact  chat  while 
some  bits  are  genuinely  for  "control" ,  causing  a  state  change  somewhere  else  in 
the  system,  others  provide  for  indications  to  the  users  as  to  the  functioning  of 
the  system. 

The  C&Z  may  be  categorized  into  three  groups: 

a)  call  control  •  these  are  created  in  Recommendations  of  the 
Q'Series 

b)  transmission  frame 'synchronous,  or  otherwise  requiring  rapid 

response 

c)  conference,  data,  and  Telematic  control  not  requiring  frame 
synchronism,  governed  by  the  multilayer  protocol  (MLP)  of 
Recommendation  H . 200/ AV . 270 . 

This  Racommendation  concerns  only  chose  C&I  coming  in  category  b)  which 
includes  a  simplified  sec  of  conference  C&I  for  multipoint  connections  of  simple 
terminals . 

2.  Praeeduree 

There  are  two  procedures:  some  frame • synchronous  C&I  are  provided  for 
directly  as  BAS  codes  in  Recommendation  H.221,  while  the  remainder  require  the 
use  of  an  escape  code. 
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2.1  C&I  cod«s  provided  in  Recommendacion  H.221 

Th«  following  codes,  whose  functions  are  defined  in  section  3,  are 
provided  in  Recommendation  H.221; 

VCF,  VCU  (procedures  for  use  in  multipoint  calls  according  to 
Recommendation  H. 200/AV . 243) ; 

LCV,  LCD,  LCA,  LCO  (for  maintenance  -  no  standardized 
procedures) . 

In  each  case  the  code  is  transmitted  in  the  BAS  position  at  an 
appropriate  time. 

2.2  Other  C&I  codes 

All  frame • synchronous  C&I  codes  not  listed  in  section  2.1  are 
transmitted  by  a  sequence  involving  the  BAS  positions  in  two  consecutive 
sub -multiframes.  In  the  first,  the  code  (111)10001  is  transmitted.  In  the 
second,  the  code  defined  in  Table  1/H.230  is  transmitted. 

It  should  be  noted  that  only  one  symbol  is  transmitted  by  this  method  - 
the  code  in  the  subsequent  sub-multiframe  is  again  treated  as  a  normal  BAS 
code. 

3.  Definitions  of  C&I  symbols 

The  full  definitions  of  these  symbols  are  set  out  below  and  code  values 
in  Table  1/H.230.  [The  first  letter  of  the  alphabetic  code-name  indicates  the 
type;  the  second  is  C  for  command,  I  for  indication;  the  third  is  for  the 
specific  function.] 

3.1  C&I  related  to  video 

VIS  Video  Indicate  Suppressed:  this  symbol  is  used  to  indicate  that 
the  content  of  the  video  channel  does  not  represent  a  normal 
camera  image.  The  video  encoder  may  be  without  video  input  or  an 
electronically- generated  pattern  may  have  been  substituted. 

VIA  Video  Indicate  Active:  complementary  to  VIS.  The  video  source  is 
the  only  one,  or,  in  the  case  that  more  video  sources  are  to  be 
distinguished,  it  is  that  designated  "video  )jll". 

VIA2  Equivalent  to  VIA,  but  designating  "video  as  the  source. 

VIA3  Equivalent  to  VIA,  but  designating  "video  #3"  as  the  source. 

VIR  Video  Indicate  Ready- to- Activate:  this  symbol  is  transmitted  by  a 
terminal  whose  user  has  decided  not  to  send  video  unless  he  will 
also  receive  video  from  the  other  end. 

VCF  Video  Command  "Freeze- Picture  Request";  this  symbol  may  be 

transmitted  prior  to  the  "video-off"  mods  switch,  to  prepare  the 
video  decoder  for  this  event.  This  symbol  is  also  transmitted  by 
a  multipoint  control  unit  (MCU)  prior  to  video  switching.  On 
receipt,  a  terminal  video  decoder  should  complete  updating  of  the 
current  video  frame  but  subsequently  display  the  frozen  picture 
until  receipt  of  the  freeze -pic cure  release  control  which  is 
embedded  In  Che  video . 
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VCU  Video  Command  "Fast  Update  Request”:  this  symbol  is  transmitted 
by  an  NCU  after  performing  a  video  switch.  It  may  also  be 
transmitted  by  a  terminal  at  the  start  of  communication  when  the 
video  decoder  Is  first  ready  to  receive.  On  receipt,  the  terminal 
video  encoder  should  enter  the  fast'update  mode  at  Its  earliest 
opportxinlty . 

3.2  C&I  related  to  audio 

AIM  Audio  Indicate  Muted:  this  symbol  Is  used  to  Indicate  that  the 
content  of  the  audio  channel  does  not  represent  a  normal  audio 
signal.  The  audio  encoder  may  be  without  audio  Input  or  an 
eleccronically*generated  tone  may  have  been  stibstituted. 

AIA  Audio  Indicate  Active:  complementary  to  AIM. 

3.3  C&I  for  maintenance  oumosea 

LCV  Loopback  Command,  "Video  Loop  Request”:  on  receipt  of  this 

symbol,  a  terminal  must  connect  the  output  of  the  video  decoder 
to  the  Input  of  the  video  encoder. 

LCD  Loopback  Command,  "Digital  Loop  Request”:  on  receipt  of  this 
symbol,  the  terminal  must  disconnect  the  output  of  the 
multiplexer  from  the  outgoing  path,  replacing  it  with  the  input 
to  the  demultiplexer.  In  the  case  of  multiple  B  or  HO 
connections,  loopback  Is  activated  in  each  connection. 

LCA  Loopback  Coonand,  "Audio  Loop  Request”:  on  receipt  of  this 

symbol,  the  terminal  should  If  possible  connect  the  output  of  the 
audio  decoder  to  the  Input  of  the  audio  encoder. 

LCO  Loopback  Command  Off:  on  receipt  of  this  symbol,  the  terminal 
must  disconnect  all  loops  and  restore  audio  and  data  paths  to 
their  normal  condition. 

3.4  C&I  related  to  simple  multipoint  conferences  not  using  MLP 

Mote  •  Some  of  the  following  codes  may  be  cancelled  by  transmission  of 

appropriate  codes  as  listed  In  Table  1/H.230  but  not  separately  defined  here. 

MCV  Multipoint  Command  Visualization-Forcing:  transmitted  by  a 
tezainal  to  force  an  associated  MCU  to  broadcast  Its  video 
signal.  (Used  to  transmit  the  picture  of  a  chairman  or  VIP, 
alternatively  to  hold  a  picture  source  during  the  transmission  of 
graphics . ) 

MIV  Multipoint  Indication  Visualization:  transmitted  by  an  MCU  to 
Indicate  to  a  terminal  that  its  video  signal  is  being  seen  by 
other  terminals  (otherwise  known  as  'On-alr'  Indication). 

MCC  Multipoint  Command  Conference:  transmitted  by  an  MCU  to  a 

terminal.  The  terminal  receiving  MCC  must  make  its  outgoing 
transfer  rate  equal  to  Its  Incoming  transfer  rate,  and  its 
outgoing  audio  rate  equal  to  Its  incoming  audio  rate. 

Note  -  The  command  could  also  be  used  to  invoke  an  on-screen  user 
indication. 
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MCS  Multipoint  Conmand  Syisnetrlcal  Data* transmission:  transmlttad  by 
an  MCU  when  setting  up  data  broadcasting.  On  receipt,  a  terminal 
must  prepare  Itself  for  data  reception  and  ensure,  by  mode  change 
If  necessary,  that  Its  outgoing  data  channel  occupies  the  same 
capacity  as  Its  Incoming  data  channel.  A  terminal  In  receipt  of 
MCS  cannot  Initiate  data  broadcasting. 

MCN  Multipoint  Command  Negating  MCS:  transmitted  by  an  MCU  at  the 
completion  of  data  broadcasting.  On  receipt,  a  terminal  onist 
close  any  outgoing  data  channel  which  It  has  opened  as  a  result 
of  the  previous  reception  of  MCS.  Following  the  end  of  data 
reception  and  the  receipt  of  MCN,  a  terminal  Is  permitted  to 
Initiate  data  broadcasting. 

MIL  Multipoint  Indication  Loop:  an  MCU  has  had  Its  ports  externally 
looped.  The  topic  Is  for  further  study. 

MIZ  Multipoint  Indication  Zero* communication:  transmitted  by  an  MCU 
to  a  terminal  for  Information,  with  the  meaning  that  no  other 
terminals  are  yet  connected  to  the  MCU. 

MIS  Multipoint  Indication  Secondary * s tatus :  transmitted  by  an  MCU  to 
a  terminal  for  Information,  with  the  meaning  that  since  other 
terminals  of  higher  capability  are  participating  In  the 
conference * cal 1 ,  this  terminal  will  not  necessarily  receive  all 
the  signals  that  are  sent  to  those  other  terminals  *  see 
Recommendation  H . 200/AV . 243 . 

MCA  Multipoint  Command  Assign* token;  possession  of  the  token  gives 

the  holding  terminal  the  rl^t  to  give  the  MCU  certain  commands  * 
see  Recommendation  H. 200/AV. 243. 

MCT  Multipoint  Command  Token*claim:  sent  by  a  terminal  to  the  MCU. 

The  MCU  accedes  to  this  claim  if  the  token  Is  unasslgned  or  has 
been  released. 

MCR  Multipoint  Command  Release* token:  sent  to  the  MCU  by  the  terminal 
holding  the  token  to  give  the  MCU  the  authority  to  reassign  the 
token  to  another  terminal  idien/if  it  receives  MCI. 

4.  Requirements  for  C&I 

The  C&I  functions  are  defined  such  that,  under  various  appropriate 
circumstances,  the  audiovisual  system  will  operate  In  a  fault* free  manner  and 
also  such  that  sympathetic  presentation  to  users  Is  possible.  Some  functions 
must  therefore  be  mandatory,  others  optional.  This  section,  together  with  the 
categorization  in  Table  1/H.230,  clarifies  the  circumstances  under  which  C&I 
fvinctlons  are  mandatory. 

CM  denotes  "conditionally  mandatory":  If  the  terminal  (or  MCU)  Is 
capable  of  entering  the  given  state,  then  It  must  transmit  the 
given  code  and,  when  leaving  that  state,  the  complementary  code. 
If  it  has  no  such  capability  It  can  Ignore  both. 

M  denotes  "mandatory”  for  all  equipments  of  either  terminal  or  MCU 
type 
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X  denotes  "non-oandecory” :  on  receipt  of  such  a  code,  it  aay  be 

unrecognized,  or  recognized  but  not  acted  upon,  or  recognized  and 
acted  upon,  entirely  at  the  discretion  of  the  manufacturer  or 
user. 

NA  denotes  that  the  code  is  not  applicable  in  that  case. 

It  will  be  noted  that  there  are  only  a  few  mandatory  requirements  on 
most  terminals.  All  audiovisual  terminals  must  recognize  and  obey  the  command  to 
make  or  break  the  digital  loopback,  and  video  loopback  if  they  have  video 
capability.  All  terminals  having  a  video  capability  must  also  obey  fast-update, 
freeze -picture,  and  HCS/MCN,  otherwise  there  will  be  system  misoperation  on  a 
multipoint  call. 


TABLE  1/H.230 


Code 

first  3  bits 

last  S  bits  in 
decimal  form 

Value 

(000) 

[0.1] 

Reserved 

[2] 

AIM 

[3] 

AIA 

[4-15] 

Reserved 

[16] 

VIS 

(171 

VIA 

[18] 

VIA2 

[19] 

VIA3 

(20-30) 

Reserved 

(31] 

VIR 

(001) 

(0] 

MCC 

(1) 

cancel -HCC 

(21 

HIZ 

(31 

cancel -MIZ 

[41 

HIS 

(51 

cancel -MIS 

[6.7] 

Reserved 

[8] 

MCT 

[9] 

NCR 

[10] 

MCA 

[11-15] 

Reserved 

transmit 

RECEIVE 

Reference  for 

Term. 

MCU 

Term. 

MCU 

procedures 

CM 

CM 

X 

X 

Section  3 . 2 

CM 

CM 

X 

X 

CM 

CM 

X 

X 

Section  3.1 

CM 

CM 

X 

X 

Section  3.1 

X 

NA 

X 

X 

H.320.  AV.312 

X 

NA 

X 

X 

H.320,  AV.312 

X 

NA 

X 

NA 

H.320 

NA 

M 

M 

NA 

H.200/AV.243 

NA 

M 

H 

NA 

•*  M 

NA 

M 

X 

NA 

It  N 

NA 

M 

X 

NA 

ft  It 

NA 

M 

X 

NA 

m  m 

NA 

M 

X 

NA 

ft  m 

X 

NA 

NA 

M 

ft  It 

X 

NA 

NA 

M 

It  M 

X 

NA 

NA 

M 

It  It 
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[16] 

MCV 

X 

NA 

NA 

M 

H.200/AV.243 

[171 

cancel -MCV 

X 

NA 

NA 

M 

N  •• 

[18] 

MIV 

NA 

H 

X 

NA 

ft  m 

[19] 

cancel-HIV 

NA 

M 

X 

NA 

n  M 

[20] 

MCS 

NA 

M 

M 

NA 

M  It 

[21] 

MCM 

NA 

M 

M 

NA 

N  m 

[22-30] 

Reserved 

[31] 

MIL 

NA 

NA 

NA 

M 

It  ft 

(111)  All  codes  forbidden 


Code  values  listed 

VCF 

X 

M 

M 

NA 

in  Reconnsendaclon  H.221, 

VOJ 

X 

M 

M 

NA 

Annex  1 

LCV 

NA 

NA 

CM 

NA 

LCA 

NA 

NA 

X 

X 

LCD 

NA 

NA 

M 

X 

LCO 

NA 

NA 

M 

X 

H.221 
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3.  RaconmantUtion  H.242 

SYSTEM  FOR  ESTABLISHING  COMMUNICATION  BETWEEN  AUDIOVISUAL 
TERMINALS  USING  DIGITAL  CHANNELS  UP  TO  2  MBIT/S 

CONTENTS 

I ■  Incroducclon 

2.  Terminal  capabilities 

2 . 1  Audio  capabilities 

2.2  Video  capabilities 

2.3  Transfer  rate  capabilities 

2 . 4  Data  capabilities 

2.5  Terminals  on  restricted  networks:  capability 

2.6  Encryption  and  extension- BAS  capabilities 

3.  Transmission 

3.1  Transmission  modes 

3.2  Establishment  of  compatible  modes  of  operation 

4 .  Frame  structure 

5.  Basic  seqxxences  for  in-channel  procedures 

3.1  Capability  exchange  sequence  A 

3.2  Mode  switching  sequence  B 

5.3  Frame  reinatatenenc  sequence  C 

6.  Mode  initialization,  dynamic  mode  switching  and  mode  0  forcing 

6.1  Mode  initialization  procedure 

6.1.1  Single  channel 

6.1.2  Additional  channels 

6.2  Dynamic  mode  switching 

6.2.1  From  a  framed  mode  to  another  framed  mode 
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6.2.2  From  a  framed  mode  to  an  unframed  mode 

6.2.3  From  an  unframed  mode  to  another  mode  ( framed  or  unframed) 

6.3  Mode  0  forcing  procedure 

6.3.1  Single  channel 

6.3.2  Two  or  more  channels 

6.4  Mode  mismatch  recovery  procedure 

7.  Recovery  from  fault  conditions 

7.1  Unexpected  loss  of  synchronization  or  frame  alignment 

7.1.1  Loss  of  frame  alignment  in  the  initial  channel 

7.1.2  Loss  of  frame  alignment  or  synchronization  in  an  additional  channel 

7.2  Recovery  from  loss  of  connection(s) 

7.2.1  Renumbering  of  channels 

7.2.2  Loss  of  an  additional  connection 

7.2.3  Loss  of  the  initial  connection 

8.  Network:  consideration:  call  connection,  disconnection  and  call 
transfer 

8 . 1  Call  connection 

8.1.1  Initial  channel 

8.1.2  Additional  channels 

8 . 2  Terminal  disconnection 

8 . 3  Call  transfer 

8 . 4  Conferencing 

8.5  PCM  format  conversion 

9.  Procedures  for  activation  and  deactivation  of  data  channels 

9.1  Data  equipment  not  conforming  to  Recommendation  H.200/AV.270 

9 . 2  Equipment  operating  with  an  MLP  according  to 
Recommendation  H . 200/AV . 270 
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9.3 
10. 

10.1 

10.2 

10.2.1 

10.2.2 

10.2.3 

10.2.4 

10.2.5 

10.2.6 
10.3 

10.3.1 

10.3.2 

10.3.3 

10.3.4 

10.3.5 

10.4 

10.5 

11. 

12. 

13. 

14. 

Appendix 

Appendix 

Appendix 

Appendix 

Appendix 


Sioulteneoue  trensaission  of  low-speed  date  and  MLP 

Procedures  for  operation  of  terminals  in  restricted  networks 

Network  aspects 

Reference  connections 

Case  1:  56  kbit/s,  V.35  interfaces 

Case  2:  n  x  56  kbit/s,  V.35  interfaces 

Case  3:  n  x  64  kbit/s  with  octet  timing  and  alignment 

Case  4:  HO  <334  kbit/s)  operation 

Case  5:  56  kbit/s  satellite  operation 

Case  6:  56  kbit/s  Interconnecting  a  64  kbit/s  network 

Transmission  formats 

Framing  signal  (56  kbit/s) 

Transmission  formats  <56  kbit/s  operation) 
n  X  56  kbit/s  operation 
n  X  HO  operation 

Dynamic  allocation  within  a  primary-rate  connection 

Interworking  between  56  kbit/s  and  64  kbit/s  terminals 

Interworking  between  HO  or  Hll  terminals  in  restricted  and  unrestricted 
networks 

Procedure  for  use  of  BAS-extension  codes 
Bit  occupancy  and  the  sequencing  of  BAS  codes 
Procedure  for  dealing  with  6B-H0  interconnection 
Procedure  for  use  of  encryption  control  signal  channel 
1;  Example  of  mode  initialization  on  two  channels 
2:  Example  of  mode-0  forcing  on  two  channels 
3:  Example  ot  use  of  message  structure 

4;  Examples  of  symmetrical  and  unsymmetrical  transmission  modes 

5;  Examples  of  application  of  mode-sequence  rules  for  data 
transmission 
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1.  Introduction 

This  RscoamondAtlon  should  be  associated  with  Reconmendations  G.72S 
(System  Aspects  for  the  use  of  the  7  kHz  Audio  Codec  within  64  kbit/s),  H.221 
(Frame  Structure  for  64-1920  kbit/s  Channels  in  Audiovisual  Teleservices)  and 
H.230  ( Frame - synchronous  Control  and  Indication  Signals  for  Audiovisual 
Systems) . 


A  number  of  applications  utilizing  narrow  (3  kHz)  and  wideband  (7  kHz) 
speech  together  with  video  and/or  data  have  been  identified,  including  high 
<}uality  telephony,  audio  and  videoconferencing  (with  or  without  various  kinds  of 
Telematic  aids) ,  audiographic  conferencing  and  so  on.  More  applications  will 
undoubtedly  emerge  in  the  future. 

To  provide  these  services,  a  scheme  is  recommended  in  which  a  channel 
accommodates  speech,  and  optionally  video  and/or  data  at  several  rates ,  in  a 
number  of  different  modes.  Signalling  procedures  are  required  to  establish  a 
compatible  mode  upon  call  set-up,  to  switch  between  modes  during  a  call  and  to 
allow  for  call  transfer. 

Some  services  will  require  only  a  single  channel,  which  could  according 
to  the  procedures  in  this  Recommendation  be  B  (64  kbit/s),  HO  (384  kbit/s), 

Hll  (1S36  kbit/s)  or  H12  (1910  kbit/s).  Other  services  will  require  the 
establishment  of  two  or  more  connections  providing  B  or  HO  channels;  in  such 
cases  the  first  established  is  called  hereafter  the  "initial  channel*  while  the 
others  are  called  "additional  channels”.  Unless  otherwise  specified,  all 
references  to  Frame  Alignment  Signal  (FAS),  Bit  Rate  Allocation  Signal  (BAS)  and 
Service  Channel  (SC)  refer  to  the  initial  channel  or,  in  the  case  of  a  higher- 
order  channel,  to  the  time -slot  No.  1  of  this  channel. 

All  audio  and  audiovisual  terminals  using  G.722  audio  coding  and/or 
G.711  speech  coding  or  other  standardized  audio  codings  at  lower  bit  rates 
should  be  compatible  to  permit  connection  between  any  two  terminals.  This 
implied  chat  a  common  mode  of  operation  has  to  be  established  for  the  call.  The 
initial  mode  might  be  the  only  one  used  during  a  call  or,  alternatively, 
switching  to  another  mode  can  occur  as  needed  depending  on  the  capabilities  of 
the  terminals.  Thus,  for  these  terminals  an  in-channel  procedure  for  dynamic 
mode  switching  is  required. 

The  following  paragraphs  develop  these  considerations  and  describe 
recommended  in-channel  procedures. 

2.  Terminal  capabilities 

The  procedures  in  this  Recommendation  are  intended  to  ensure  that  only 
chose  signals  are  traxxsmicced  which  can  be  received  and  appropriately  treated  by 
the  remote  terminal,  without  ambiguity.  This  requires  that  the  capabilities  of 
each  terminal  to  receive  and  decode  be  known  to  Che  other  terminal.  Some 
capabilities  are  defined  with  a  hierarchical  structure:  a  terminal  with 
capability  value  N  is  Chen  also  capable  of  all  lower  values.  Where  there  is  no 
hierarchy,  Chen  two  or  more  codes  of  the  same  type  may  have  to  be  transmitted  in 
successive  frames. 

The  following  paragraphs  define  audio,  video,  transfer  rate,  and  data 
race  capabilities  of  a  terminal.  It  is  not  necessary  chat  a  terminal  understand 
or  score  all  incoming  capabilities.  Those  which  are  not  understood,  or  which 
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cannoc  b«  used  (because  the  terminal  has  no  means  to  transmit  corresponding 
information),  can  be  ignored. 

The  total  capability  of  a  terminal  to  receive  and  decode  various 
signals  is  made  kno%m  to  the  other  terminal  by  transmission  (see  section  3.1)  of 
its  capability  set,  consisting  of  the  BAS -capability  marker  followed  by  all  of 
the  current  capabilities.  The  codes  are  specified  in  Recommendation  H.221, 

Annex  1;  Table  1/H.242  (see  section  12)  summarizes  the  capabilities  which  may  be 
included  in  a  valid  sec.  The  transmission  order  is  immaterial  with  the  exception 
that  video  picture  format  values  must  be  followed  by  minimum  picture  interval 
values . 

Note  -  G.72S  terminals  send  only  a  single  capability  value  without  a  marker.  The 
value  is  valid  only  if  repeated  at  least  once:  this  may  be  used  to  identify  a 
G.72S  terminal.  Having  so  identified,  the  H.242  terminal  should  follow  the 
procedures  of  G.72S. 

2.1  Audio 

Audio  capability  values  are  defined  in  Recommendation  H.221,  Annex  1. 

All  audiovisvial  terminals  intended  for  interregional  operation  should 
be  capable  of  transmitting  and  receiving  A-  and  M*law  G.711. 

Normally,  it  is  not  necessary  to  transmit  G.711  capabilities  in  a  set 
containing  other  audio  capabilities.  Inclusion  of  just  one  value  (A  or  /i)  must 
be  interpreted  as  a  request  not  to  send  audio  encoded  to  the  ocher  law  •  see 
section  6.3.1. 

2.2  Video  capabilities 

Video  capabilities  are  defined  in  Recommendation  H.221,  including: 
picture  format:  quarter-CIF,  or  both  quarter-CIF  and  GIF; 

-  minimum  picture  interval  (MPI):  1/29.97,  2/29.97,  3/29.97, 

4/29.97  seconds. 

The  quarter-CIF  value  must  be  followed  by  one  MPI  value.  The  full-CIF 
value  must  be  followed  by  two  MPI  values,  the  first  applicable  to  quarter-CIF 
and  the  ocher  to  GIF. 

2.1  Transfer  rate  capabilities 

Transfer-race  capabilities  are  defined  in  Recommendation  H.221. 

The  capability  to  receive  a  given  number  of  multiple  64  kbit/s  channel 
includes  the  capability  to  receive  fewer  64  kbic/s  channels.  Similarly,  the 
capability  to  receive  a  given  number  of  HO  channels  includes  the  capability  to 
receive  fever  HO  channels.  In  both  cases  the  receiving  terminal  will  synchronize 
the  connected  additional  channels  to  the  initial  channel  and  maintain  chat 
synchronism  throughout  the  period  of  connection. 

All  ocher  ranges  of  capability  must  be  signalled  by  inclusion  in  the 
capability  set  of  mote  than  one  transfer  rate  capability  code.  For  example,  a 
terminal  may  list  its  transfer-rate  capabilities  as  {2B  and  HO  and  Hll  and  H12); 
in  this  case  IB  capability  is  also  implied. 
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2.4  Bata  gapabtlUigg 

Data  eapabillcles  are  defined  in  Recommendation  H.221. 

If  a  terminal  is  able  to  accept  more  chan  one  data  rate  of  whatever 
type  (LSD,  HSD,  MLP,  H-MLP)  Chen  all  relevant  values  muse  be  included  in  che 
capability  sec.  Scacement  of  one  value  does  noc  include  any  oCher  values. 

2.5  Terminals  on  restricted  networks:  capability 

A  terminal  connected  to  a  network  whose  B*channels  are  effectively 
restricted  to  p  x  56  kbit/s  (p  -  1  to  6) ,  or  whose  channels  at  HO  or  higher  are 
restricted  by  ones -density  considerations,  must  declare  the  capability  value 
(100) [22]  as  given  in  Recommendation  H.221.  All  terminals  intended  for 
interworking  with  terminals  on  restricted  networks  must  have  che  capability  to 
respond  to  this  code  according  to  Annex  2. 

2.6  Encryption  and  extension-BAS  capabilities 

The  capabilities  are  defined  in  Recommendation  H.221. 

3.  Transmission 

3.1  Transmission  modes 

Audio  modes  of  operation  are  defined  in  Recommendation  H.221,  Annex  1, 

Audio  Commands. 

For  analogue  telephone  terminals,  it  may  be  assumed  chat  the  speech 
signal  is  converted  to  PCM  to  G.711  at  a  digital  network  interface.  These 
terminals  are  viewed  as  working  in  Mode  OU  when  connected  to  wideband  speech 
terminals . 

The  video  transmission  is  governed  by  the  "video -on"  and  "video -off" 
commands.  When  switched  on,  che  video  signal  occupies  all  of  che  capacity,  both 
in  Che  initial  channel  and  in  any  additional  channels,  which  is  not  specifically 
allocated  to  other  signals  by  other  commands.  Thus  different  video  bit  rates 
will  result  from  audio,  transfer -rate,  ECS  and  data  commands  the  resultant  video 
bit  rate  being:  (transfer  rate,  less  audio  rate,  less  data  rate  if  present,  less 
encryption  control  channel  if  present,  less  FAS  and  BAS  in  all  the 
chaimels/time-slots  where  they  are  present) . 

Transfer-Rate  Modes  are  defined  in  Recommendation  H.221,  and  specify 
Che  total  capacity  of  che  communication  effective  in  che  subsequent 
sub -multifraae . 

Data  modes  are  defined  in  Recommendation  H.221,  and  specify  only  Che 
bit  rate  and  bit  positions  used  for  a  user  data  signal.  The  protocol  used  for 
data  applications  is  defined  by  che  terminals,  but  see  also  section  9. 

3.2  Establishment  of  compatible  modes  of.  operation 

AC  Che  beginning  of  the  communication  phase  of  a  call,  all  terminals 
start  to  work  in  Mode  OF.  Terminals  ocher  chan  those  limited  to  G.711  capability 
will  Chen  begin  an  initialization  procedure. 
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This  procedure  (further  described  In  section  6)  consists  of: 

the  transnisslon  of  Infonsetlon  concerning  the  capabilities  of 
the  respective  terminals  for  receiving  and  decoding  audio,  video, 
transfer  rate,  data  rates  and  other  capabilities; 

the  determination  of  a  suitable  transmission  mode,  consistent 
with  the  known  capabilities  of  both  terminals.  An  example  Is 
given  in  Appendix  4(a) ;  In  tihlch  the  transmission  mode  Is  the 
same  In  both  directions,  but  the  H.242  procedures  are  equally 
applicable  to  systems  in  which  asymmetric  bidirectional 
coismunlcatlon  Is  optimal  (examples  are  surveillance  -  see 
Appendix  4(b)  -  and  retrieval  services) ; 

switching  to  this  mode  establishing  additional  channels  If 
relevant. 

The  terminals  connected  to  a  call  may  change  during  the  call.  This  may 
require  re* Initialization  In  order  to  Identify  the  terminal  type  and  to  re¬ 
establish  the  desired  mode  of  operation.  In  particular,  this  feature  Is  used  In 
mode  0  forcing,  which  Is  necessary  in  the  case  of  a  call  transfer  (see 
section  8) . 

4.  Frame  structure 

The  frame  structure  described  in  Recommendation  H.221  Is  xised  for  mode 
Initialization  and  dynamic  mode  switching  (see  the  following  sections)  and  more 
generally  to  define  the  multiplex  of  the  various  bit  streams  (audio,  video, 
data,  encryption  control  signal,  frame  structure)  within  the  frame. 

Recommendation  H.221  defines  a  Bit  rate  Allocation  Signal  (BAS)  which 
Is  used  Inter  alia  to  allocate  sub -channels  and  to  Indicate  the  coding 
algorlthffl(s) . 

BAS  codes  are  classified  by  the  value  of  the  first  three  bits  which 
represent  the  BAS  attribute :  each  attribute  may  therefore  have  up  to  32  defined 
ygiugg. 


Four  BAS  attributes  are  rnmniands •  they  define  the  multiplex  within  the 
next  and  following  sub -multiframes,  as  well  as  audio  coding  algorithm,  and 
therefore  command  the  distant  receiver  to  treat  the  signals  accordingly.  The 
four  atcributss  are  Independent;  that  is,  a  value  of  one  attribute  does  not 
modify  that  of  another. 

Further  BAS  attributes  are  defined  to  signal  terminal  capabilities  to 
the  distant  terminal.  When  received,  these  attributes  do  not  directly  affect  the 
current  transmission  mode.  However,  they  may  lead  to  the  Initiation  of  a 
specific  action  to  be  carried  out  by  the  terminal.  This  feature  is  utilized  In 
the  mode  Initialization  procedure  and  In  the  Mode  0  forcing  procedure  (see 
section  6) . 

The  third  bit  of  the  H.221  Frame  Alignment  Signal  (FAS)  in  odd  frames 
of  the  initial  channel,  called  the  A-blt,  Is  set  to  1  on  loss  of  frame  or 
multiframe  alignment,  and  Is  sat  to  0  on  acquiring  both  frame  and  multiframe 
alignment  (note) .  Consequently,  a  terminal  which  is  receiving  a  framed  signal 
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with  the  A-blt  set  to  0  can  assume  that  the  distant  terminal  is  able  to  act  upon 
a  change  of  BAS. 

Note  •  A  terminal  having  capabilities  only  for  single-channel  working  and 
without  encryption  capability,  does  not  need  to  seek  and  gain  aniltiframe 
alignment  since  the  latter  serves  for  numbering  and  synchronizing  multiple 
channels. 

3.  Basic  sequences  for  in-channel  procedures 

Three  signalling  sequences  are  defined  in  this  section.  These  sequences 

are  used  as  the  building  blocks  for  the  procedures  defined  in  sections  6  and  7. 

5.1  Capability  exchange  sequence  A 

The  capability  exchange  sequence  forces  framing  in  both  directions  of 
transmission  and  the  exchange  of  terminal  capability  codes.  Either  terminal  may 
initiate  the  sequence  and  there  is  no  problem  caused  by  both  doing  so 
simultaneously  or  nearly  simultaneously.  Capability  BAS  should  not  be  sent 
unnecessarily  when  the  incoming  signal  is  unframed. 

The  terminal  X  which  initiates  the  capability  exchange  sequence  must 
first  switch  to  a  framed  mode  if  previously  transmitting  unframed;  it  then  sets 
a  timer  T1  (value  10  seconds)  and  transmits  its  current  capability  set  (see 
section  2)  repetitively,  or  at  least  one  complete  set  followed  by  the  marker 
code  (to  indicate  completion  of  the  set);  these  capabilities  will  be  one  or  more 
of  the  set  listed  in  Table  1/H.242. 

When  Y  first  detects  any  incoming  capability  code  except  neutral  (see 
section  S.3),  it  begins  transmission  of  its  own  set  of  capability  codes.  This, 
of  course,  requires  switching  to  a  framed  mode  if  transmission  had  been 
unframed.  To  ensure  that  each  receives  the  complete  set  of  capabilities  of  Che 
other,  they  must  continue  repetitive  transmission  beyond  the  time  they  detect 
incoming  A  -  0  by  at  least  one  complete  set  and  the  marker  coda. 

Note  -  See  note  on  G.72S  terminals  in  section  2. 

There  are  three  possible  outcomes; 

Outcome  I:  within  the  timer  expiration  period,  multiframe  alignment  has 
been  gained,  the  A  bit  is  received  with  a  value  of  0  and  the  complete  set  of 
capability  BAS  codes  of  the  distant  terminal  has  been  validated.  In  this  case 
the  sequence  is  completed  successfully. 

Note  -  If  sequence  A  is  initiated  while  incoming  A  »  0,  repetition  of  the  set  is 
not  necessary. 

Outcome  II :  the  timer  has  expired  without  multiframe  alignment.  In  this 
case,  the  sequence  failed. 

Outcome  III:  the  timer  has  expired  with  multiframe  alignment  achieved, 
but  without  either  the  validation  of  the  A  bit  as  0  or  the  receiving  of  the 
complete  sec  of  the  distant  terminal's  capability  BAS  codes  (or  both).  In  this 
case,  the  sequence  is  restarted.  Outcome  III  should  be  notified  to  the  user  as  a 
potential  fault  condition  (which  might,  however,  be  in  the  remote  terminal). 
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3.2  .wttthinK 

Mod«  swlcehlng  is  performed  using  BAS  command  codes,  each  being 
effective  from  the  beginning  of  the  even  frame  following  the  sub-multiframe  in 
which  the  code  is  first  transmitted.  Mode  switching  is  possible  at  any  time 
during  a  communication,  after  the  initialization  procedure  has  been  completed. 

When  Che  transmitting  terminal  signals  the  mode  of  operation  this  is 
valid  from  the  next  sub- multiframe.  It  is  essential  to  note  that  transmitted 
signals  must  always  be  in  accordance  with  the  known  capabilities  of  the  remote 
terminal  to  receive  and  decode;  in  the  absence  of  such  knowledge  only  mode  OF  or 
OU  (audio  to  Recommendation  G.711)  may  be  sent..  If  a  change  of  capability, 
indicated  in  perfoirming  sequence  A.  has  the  result  that  the  current  mode  is  no 
longer  recelvable/decodable,  there  must  be  a  switch  as  soon  as  possible  to  a 
mode  which  can  be  received  and  decoded. 

The  receiving  terminal  decodes  and  validates  the  BAS  code,  and  switches 
its  receive  mode  of  operation  accordingly.  If  for  any  reason  a  terminal  receives 
a  BAS  command  it  cannot  obey,  a  mode  mismatch  may  result  -  see  section  6.3. 

In  addition  to  switching  of  the  audio  mode,  mode  switching  Includes 
turning  video  off  or  on;  the  adoptlon/cessatlon  of  use  of  additional  channels; 
the  opening/closing  of  the  encryption  control  channel;  the  opening/closing  of  a 
data  channel. 

The  mode  switc'-  ,ig  is  in  principle  performed  independently  for  the  two 
transmission  directions;  some  applications  may  be  fundamentally  asymmetric.  For 
conversational  services  the  terminal  procedures  will  generally  be  such  as  to 
provide  symmetrical  transmission,  though  this  is  not  mandatory. 

3.3  Frame  reinstatement  sequence  C  (see  Figure  1/H.242) 

If  terminal  A  is  transmitting  unframed  but  receiving  framed,  frame 
reinstatement  consists  in  the  insertion  of  FAS  and  BAS  into  the  first  16  bits  of 
the  service  channel,  waiting  for  incoming  A  -  0;  the  overlaid  frame  can  contain 
neutral  BAS  capability  to  avoid  triggering  a  full  capacity  exchange. 

A  terminal  A  which  is  receiving  unframed  may  wish  the  remote  terminal  B 
CO  reinstate  framing;  to  do  this,  A  must  first  itself  reinstate  framing  if  it  is 
not  already  transmitting  framed  and  then  send  the  neutral  BAS  capability;  B  must 
respond  by  reinstating  framing  in  order  to  return  the  neutral  BAS  capability  and 
A  •  0,  and  continuing  this  at  least  until  it  receives  A  «  0  itself. 


CCITT\COMXV\RAPP\R037t3 . TXS 


-  49  - 

COW  XV-R  37 -E 


(wichouc  considaration  of  rescricced  netr.jorks) 


Is  current  outgoing  signal 
64  kblt/s  Data?  (Mode  10) 


Is  current  outgoing 
signal  64  kbit/s  Video? 


Is  current  outgoing 
signal  Audio  Mode  1? 


The  current  mode  must 
be  PCM  audio 


Send  framed  signal  with  suitable  Data  Command 
(62.4  kblt/s  or  less)  •  note  that  data  Is 
->  corrupted  in  the  receiver  until  FAS  is 

recovered  at  ocher  end;  interleave  neutral-cap 
if  relevant 


Send  framed  signal  with  (000) [31]  and  (010) [1] 
->  -  note  chat  video  is  corrupted  in  the  receiver 
until  FAS  is  recovered  at  ocher  end; 
interleave  neutral -cap  if  relevant 


Overlay  framing  without  mode  change;  use 
->  (000) [6]  and  interleave  neutral -cap  if 
relevant 


Send  Mode  OF  with  (000) [18  or  19] 
->  interleave  neutral-cap  if  relevant 


(application  to  rescricced  networks) 


Is  current  outgoing 
56  kbit/s  Data? 


Is  current  outgoing 
56  kblt/s  Video? 


Is  current  outgoing 
signal  56  kbit/s  G.722? 


The  current  mode  must 
be  PCM  audio 


Send  framed  signal  with  suitable  Data  Command 
(54.4  kbic/s  or  less)  -  note  that  data  is 
->  corrupted  in  the  receiver  until  FAS  is 

recovered  at  ocher  end;  interleave  neutral-cap 
if  relevant 


Send  framed  signal  with  (000) [31]  and 
->  (010) [1  or  2]  -  note  that  video  is  corrupted 
in  the  receiver  until  FAS  is  recovered  at 
ocher  end;  interleave  neutral-cap  if  relevant 


Overlay  framing  without  mode  change  and 
->  interleave  neutral -cap  if  relevant 


Send  Mode  OF  with  (000) [18  or  19]  and 
->  interleave  neutral -cap  if  relevant 


FIGURE  1/H.242 
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6 .  Mode  Initlalizatton.  dynamic  mode  switching  and  moda  0  forcing 

Audiovisual  terminals  will  be  connected  to  digital  networks  where  other 
kinds  of  terminals  will  also  be  connected:  C.711  terminals  but  also  data 
terminals.  Telematic  terminals,  servers,  etc.  When  compatibility  between  the 
different  services  involving  chose  terminals  is  required  an  initialization 
procedure  is  necessary. 

When  automatic  compatibility  is  required,  a  procedure  based  on  the 
sequences  defined  in  section  S  is  used. 

For  call  transfer  or  mode  mismatch  recovery  it  is  necessary  for 
tenninals  to  operate  in  the  common  mode  OF  and  a  mode  0  forcing  procedure  is 
required,  again  based  on  Che  sequences  defined  in  section  3. 

AC  Che  commencement  of  the  call,  after  call  transfer  and  after  the 
procedure  of  section  6.3,  there  is  a  need  for  an  initialization  procedure  to 
ensure  chat  the  two  connected  terminals  can  operate  in  the  most  suitable  common 
mode . 

6.1  Mode  initialization  procedure 

6.1.1  Single  channel 

The  initialization  procedure  begins  as  soon  as  a  connection  message  is 
received  from  the  network,  or  any  indication  meaning  that  the  physical 
connection  is  established. 

AC  the  beginning  of  mode  initialization,  each  terminal  will  start  to 
transmit  in  mode  OF. 

The  receive  part  of  the  terminal  should  be  in  Frame  Search  and  the 
receive  audio  is  mode  OF.  Sequence  A  is  started. 

Upon  completion  of  sequence  A  according  to  outcome  I ,  see 
Figure  2/H.242  (outcome  la),  sequence  B  will  commence.  The  BAS  code  which  is 
sent  in  sequence  B  is  calculated  from  the  knowledge  of  the  capabilities  of  the 
local  and  distant  terminals  and  is  used  to  switch  to  a  suitable  working  mode. 
This  process  may  involve  "terminal  procedures”  effecting  choices  made  by  the 
user  or  preset  in  the  terminal.  An  example  illustrating  conformance  to  a  defined 
celeseirvice  is  given  in  Recommendation  H.320. 

In  the  event  of  outcome  II,  the  terminal  will  switch  its  transmission 
and  reception  to  node  OU.  The  receive  part  of  the  terminal  should  remain  in 
Frame  Search  throughout  the  call. 

In  the  event  of  outcome  III,  timer  T1  is  reset  and  the  terminal  remains 
within  sequence  A. 

The  Initialization  procedure  is  completed  when  both  terminals  have 
switched  to  the  desired  working  mode<s). 
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6.1.2  Additional  channels 

A  possibility  of  adding  more  channels  is  established  from  the 
capability  exchange  sequence.  The  calling  terminal  may  then  immediately  begin 
establishing  the  additional  connections.  When  each  is  established,  it  transmits 
only  FAS  and  BAS  on  that  channel,  setting  a  timer  of  value  10  seconds. 
S)mchronizacion  with  the  initial  channel  is  performed  according  to 
Recommendation  H.221,  section  2.7.  When  the  incoming  A  bits  on  additional 
channels  are  observed  to  be  0,  mode  switching  to  occupy  sequentially  numbered 
channels  is  initiated  by  an  appropriate  transfer- rate  command  BAS.  If  the  timer 
has  expired  without  receiving  A  -  0,  it  is  dealt  with  as  a  fault  condition. 

As  the  buffering  process  may  involve  Che  insertion  of  additional  delay 
in  Che  initial  channel,  which  may  already  be  carrying  user  information  (speech, 
video,  data),  it  may  be  necessary  to  make  some  provision  for  this  interruption 
(e.g.,  short-term  muting  of  audio  output). 

As  additional  channels  achieve  synchronization  they  are  sequentially 
numbered  using  both  FAS  and  BAS  numbering  as  provided  in  Recommendation  H.221. 

An  example  of  mode  initialization  on  two  channels  is  given  in 
Appendix  1 . 

6.2  Dynamic  mode  switching  (see  Figure  3/H.242) 

The  mode  switching  procedure  makes  use  of  Che  frame  structure  specified 
in  section  4  and  of  Che  sequences  defined  in  section  5.  It  should  be  noted  that 
all  terminal  receivers  must  remain  in  frame  search  throughout  the  call. 

When  Che  terminal  is  receiving  in  a  framed  mode,  chat  is,  it  is  capable 
of  decoding  bit  A,  mode  switching  should  be  delayed  if  Che  A  bit  is  set  to  1; 
eventually  Che  Mode  Mismatch  Recovery  procedure  as  described  in  section  6.4 
might  be  used. 

When  Che  terminal  X  wishing  to  make  a  mode  switch  is  receiving  unframed 
signals,  Che  capability  exchange  sequence  may  be  xiaed  first  to  force  the  ocher 
terminal  Y  to  a  framed  mode;  hence  terminal  X  can  check  for  incoming  A  ••  0. 

This  use  of  sequence  A  is  particularly  necessary  if  X  was  previously 
transmitting  unframed  signals,  since  Y  would  not  be  in  a  position  to  deal  with  a 
mode  change  ffom  X  until  it  had  regained  frame  alignment  (see  section  6.2.3).  If 
X  had  previously  been  transmitting  framed  signals,  the  capability  exchange 
sequence  may  be  omitted  on  the  assumption  that  if  Y  had  unexpectedly  lost  frame 
alignment  it  would  already  have  attempted  a  recovery  procedure  (see  section  7) . 
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6.2.1  Dynamic  mode  awltching  from  a  framed  mode  to  another  framed  moiis 

The  baalc  sequence  "Mode  Swicching”  described  In  section  S.2  Is  used. 

At  the  transmitting  terminal,  If  a  BAS  command  Is  transmitted  to  signal 
a  new  mode,  the  transmitter  must  operate  In  the  appropriate  mode  from  the  first 
octet  of  the  next  sub-multlframe . 

Similarly,  at  the  receiving  terminal.  If  the  received  BAS  signals  a  new 
mode,  the  receiver  m\isc  operate  In  the  appropriate  mode  from  the  first  octet  of 
the  next  sub-multlframe. 

6.2.2  Dynamic  mode  switching  from  a  framed  mode  to  an  unframed  mode 

As  above  In  6.2.1,  the  basic  sequence  "Mode  Switching"  described  In 
section  5.2  Is  used. 

However,  as  the  BAS  for  signalling  an  unframed  mode  Is  transmitted  for 
a  single  sub-multlframe,  a  mode  mismatch  may  occur  In  drastic  error  conditions. 
Optionally,  a  method  may  be  used  to  Improve  the  reliability  of  the  switching: 
the  new  BAS  value  In  the  basic  sequence  "Mode  Switching"  Is  repeated  three 
times;  this  will  cause  a  temporary  corruption  of  the  least  significant  bit  of 
the  received  Information. 

6.2.3  Dynamic  mode  switching  from  an  unframed  mode  to  another  mode  (framed  or 
unframed) 

The  basic  sequences  "Frame  Reinstatement”  and  "Mode  Switching”  are 
sequentially  transmitted,  the  former  Including  capability  exchange  If 
necessary. 

6.3  Mode  0  forcing  procedure  -  see  Figure  4/H.242 
6.3.1  Single  channel 

Where  It  Is  necessary  to  ensure  that  both  terminals  are  operating  In 
Mode  0  (for  Instance  before  call  transfer),  this  procedure  Is  used. 

The  forcing  terminal  uses  dynamic  mode  switching  (section  6.2)  with  BAS 
audio  command  to  switch  to  Mode  OF,  followed  by  sequence  A  using  BAS  (100) 
Indicating  only  G.711  audio  capability.  The  value  [1  or  2]  appropriate  to  the 
terminal's  own  region  Is  used  In  case  the  call  is  to  be  transferred  to  a  local 
G.72S  Type-0  terminal.  On  receipt  of  this,  the  remote  terminal  Is  obliged  to 
switch  to  Mode  OF  also  using  the  Indicated  law  for  Its  encoder  and  decoder.  The 
procedure  is  complete  when  the  forcing  terminal  detects  Incoming  Mode  OF. 

Changes  of  network  configuration  can  now  be  implemented  (see  section  8). 
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6.3.2  Two  or  aora  channels 

In  thl*  c«**  th«  "Mod*  0"  forcing  is  applied  to  the  initial  channel 
only,  and  separate  considerations  apply  to  treatment  of  the  additional  channels. 
Three  cases  are  considered  here  by  way  of  guidance  for  the  muItiole-B  case: 

a)  Additional  channels  drooped:  this  would  be  necessary,  for 
example,  prior  to  disconnection.  The  procedure  is  as  for  one  channel,  the 
forcing  terminal  declaring  capability  of  PCM  audio  only  with  transfer  rate 
capability  of  1  x  64  kbtt/s;  this  will  result  in  mode  switches  successively  to 
"data  OFF",  "video  OFF"  and  audio  mod*  OF  or  OU,  such  that  all  additional 
channels  are  vacated  and  can  be  disconnected. 

b)  Additioniil  channels  idle:  this  is  the  same  as  a)  above,  except 
that  the  forcing  terminal  makes  no  move  to  disconnect;  the  channels  carry  FAS, 
the  multiframe  number  and  the  BAS  indicating  channel  number;  the  content  of  the 
remainder  of  the  idle  channels  is  irrelevant. 

c)  Additional  channels  maintained  active:  this  might  be  beneficial 
in  some  recovery  procedures.  The  forcing  terminal  declares  a  capability  of  PCM 
audio  plus  transfer  rat*  unchanged  from  its  previous  value,  and  then  itself 
switches  to  the  appropriate  mode. 

An  example  of  Mod*  0  forcing  a)  is  given  in  Appendix  2. 

6.4  Mode  mismatch  recovery  orocedutfl 

In  the  case  where  mod*  mismatch  has  occurred,  the  Mod*  0  forcing 
procedure  may  be  used  to  establish  a  common  working  mode .  Following  this 
procedure,  re- initialization  can  be  achieved  by  using  the  mode  initialization 
procedure . 

7.  Recovery  from  fault  condltiona 

The  provisions  of  this  section  are  not  wholly  mandatory.  In  general  it 
is  expected  chat  fault  conditions  will  be  rare  and  it  may  be  uneconomical  to 
provide  elaborate  recovery  procedures  to  cover  all  eventualities.  It  is 
mandatory  chat  proper  indications  of  fault  condition*  be  transmitted  on  the 
outgoing  channel(s)  -  in  particular,  A  must  be  set  to  1  where  appropriate 
conditions  for  A  -  0  are  not  met.  Other  action  to  be  taken  on  losing  frame 
alignment,  multiframe  alignment,  synchronism,  or  a  connection,  or  on  receiving 
Incoming  A  -  1,  is  presented  here  for  guidance. 

7.1  Unexpected  loss  of  synchronization  or  frame  aligmaanS 

7.1.1  Loss  of  frame  alignment  in  the_iniCiaI  ChBimgl 

If  a  terminal  unexpectedly  loses  frame  alignment  on  its  receive  path, 
timer  T3  is  sec  (value  for  example  1  second)  and  Incoming  information  is 
discarded  if  unintelligible.  During  this  time  the  status  of  the  framing  in  the 
receive  direction  is  monitored: 

a)  If  framing  is  recovered  before  the  timer  expires,  the  normal 
operation  is  resumed. 

b)  If  framing  is  not  recovered  before  the  timer  expires,  the 
terminal  goes  to  the  Mod*  0  forcing  procedure  followed  by  re¬ 
initialization. 
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7.1.2  Losa  of  frame  alignment  of  synchronization  in  an  additional  channel 

If  a  cerminal  unexpectedly  loses  synchronization  (including  that  due  to 
loss  of  frame  alignment)  on  an  additional  channel,  a  timer  T3  is  set,  outgoing 
A-bit  is  set  to  1  and  incoming  information  discarded  if  unintelligible;  if  the 
loss  of  this  information  also  causes  Information  on  other  channels  to  become 
meaningless  that  also  is  discarded. 

a)  if  synchronization  is  recovered  before  the  timer  expires,  normal 
operation  is  resumed;  this  takes  into  account  recoverable 
synchronization  loss  due  to  bit  or  synchronization  errors  on  the 
transmission  line; 

b)  if  synchronization  is  not  recovered  before  the  timer  expires,  the 
mode  0  forcing  procedure  may  be  used. 

7.2  Recovery  from  loss  of  connectlon(s) 

Loss  of  a  connection  means  that  end>co>end  transmission  on  that  channel 
has  been  discontinued,  so  that  all  apparently  received  bits  are  meaningless.  The 
receiver  will,  of  course  lose  frame  alignment  and  may  follow  the  procedures  of 
section  7.1.  However,  an  indication  may  be  available  from  the  network  (D-channel 
or  otherwise)  that  the  conn'ction  has  been  lost;  in  this  case  the  procedures  of 
this  section  are  followed.  lu  is  assumed  that  connection  loss  is  bidirectional; 
Che  case  of  loss  in  one  direction  only  is  for  further  study. 

7.2.1  Renumbering  of  channels 

This  procedure  is  used  for  reconstructing  the  remaining  normal 
additional  channels  when  one  additional  channel  breaks  down. 

i)  Hake  Che  transmission  mode  of  all  channels  into  "framed". 

ii)  Vacate  the  sending  additional  channel(s). 

Hi)  Renumber  the  additional  channel(s). 

iv)  Wait  for  the  synchronization  establishment  of  the  remote  terminal 
and  then  expand  communication  onto  the  additional  channels. 

7.2.2  Loss  of  an  additional  connection 

If  any  remaining  channels  are  unframed  (for  example,  data  transmission) 
they  m\ist  imnadiately  have  frame  structure  (according  to  Recommendation  H.221) 
reimposed  and  maintained  until  conditions  have  returned  to  normal.  The  outgoing 
.A-bic  on  additional  channels  is  sec  to  1  if  the  incoming  direction  is  unframed 
or  out  of  sequence,  or  if  synchronism  has  been  lost. 

If  Che  lost  channel  was  carrying  part  of  a  signal  (such  as  encoded 
video)  which  also  involved  other  channels,  so  that  it'  loss  renders  the 
information  in  chose  ocher  channels  meaningless,  then  by  dynamic  mode  switching 
chose  channels  are  vacated. 

The  next  step  is  to  renumber  the  available  channels  if  appropriate,  to 
obtain  a  continuous  sequence;  this  is  done  using  the  procedure  of 
section  7.2.1. 


CCITT\C0MXV\RAPP' R037E3  TXS 


-  58  - 

COM  XV-R  37-E 


OynaiBlc  node  switching  Is  applied  to  re-establish  the  video  or  other 
transmission  on  the  channels  for  which  Incoming  A-blts  are  zero. 

In  the  event  that  the  lost  channel  be  reconnected,  it  Is  added  to  the 
capacity  In  the  same  way  as  at  the  start  of  the  call. 

7.2.3  Loss  of  the  Initial  connection 

This  results  In  the  loss  of  the  Initial  channel  In  both  directions. 

Both  terminals  Immediately  regard  ^1  as  the  Initial  channel  and  transmit  thereon 
the  following  BAS: 

1}  reinstatement  of  FAS  and  BAS  In  any  tinframed  channels; 

II)  transfer  rate  (001) [0  or  6]  -  code  having  the  effect  of  vacating 
all  additional  channels;  also  audio  command  (000)  unchanged  from 
previous  value; 

III)  transfer  race  (001) [17]  on  original  second  channel.  Indicating 
loss  of  original  channel,  and  from  next  sub-mulclframe  original 
second  channel  subscltutes  for  original  Initial  channel; 
simultaneously  any  additional  channels  are  renumbered  In 
sequence ; 

Iv)  wale  for  confirmation  that  the  synchronism  at  the  remote  terminal 
Is  re talned/re gained  (all  incoming  A^  "  0) ; 

v)  expand  communication  onto  all  channels  using  appropriate 
transfer -race  command. 

(Note  •  As  a  result  of  this  procedure,  sending  and  receiving 
Initial  channels  may  not  be  on  the  same  connection.) 

vl)  Che  terminal  tries  to  re-establish  the  lost  channel. 

8.  Network  consideration;  call  connection,  disconnection  and  call 

scanafei 

8.1  Call  gpniwctton 

8.1.1  Inlslal  ghanntl 

It  Is  assumed  that  the  terminals  for  switched  network  operation  will 

have  a  signalling  arrangement  for  originating  calls  over  the  network. 

In  the  ease  that  the  network  provides  an  Indication  that  the  connection 
is  established  (CONNECT-ACK  message) ,  the  originating  terminal  will  sec  its 
transmit  and  receive  audio  modes  to  PCM  and  begin  the  mode  initialization 
procedure  following  the  coiuiectlon  establishment  Indication.  Where  the  network 
does  not  provide  an  Indication  of  connection  establishment  the  originating 
terminal  will  begin  the  mode  Initialization  procedure  Immediately. 

Upon  answering  a  call  the  terminal  will  begin  the  mode  initialization 
procedure . 

Terminals  for  use  on  leased  circuits  may  have  a  means  for  sending  the 
alerting  signal  to  the  distant  terminal  and  for  answering  the  alerting  signal. 

In  this  case,  the  sending  of  the  alerting  signal  is  equivalent  to  dialling  and 
Che  foregoing  procedures  apply. 
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Whenever  a  terminal  is  manually  reset,  or  recovers  from  a  fault 
condition,  the  terminal  will  begin  the  Mode  0  forcing  procedure  of  section  6.3. 
Then  the  terminal  will  begin  mode  initialization. 

8.1.2  Additional  channels 

Call  connection  to  provide  additional  channels  may  be  initiated  by  one 
of  the  following: 

a)  manually; 

b)  on  completion  of  uhe  capability  exchange  sequence  indicating 
mutual  additional-channel  capability; 

c)  at  some  time  later  than  in  b) ,  prompted  by  user  action. 

The  choice  between  these  will  depend  on  service  provision  and/or 
terminal  procedures. 

When  the  establishment  of  connection  is  known  to  the  terminal,  the  mode 
initialization  procedure  of  section  6.1.2  is  applied. 

During  call  establishment,  an  originating  terminal  should  reserve 
additional  channels  by  not  answering  incoming  calls  on  chose  channels  until  it 
is  determined  whether  the  additional  channels  will  be  used  in  the  connection. 

This  prevents  multiple  call  collisions  and  contention  for  the  available 
channels.  A  network  solution  is  under  study. 

8.2  TflCTlnal  4ia,g.gim<ggl9n 

When  a  terminal  disconnects  from  a  call,  the  terminal  must  first 
initiate  the  Mode  0  forcing  procedure,  await  completion  of  the  procedure  and 
Chen  allow  the  actual  disconnection  of  the  call  Co  occur. 

8 . 3  Call  transfer 

As  a  consequence  of  the  above,  the  terminal  which  continues  to 
participate  in  a  transferred  call  will  be  receiving  in  a  PCM- forced  state  and 
therefore  will  be  transmitting  its  capability  set  in  framed  PCM.  When  the 
transferred  to  terminal  answers ,  mode  initialization  will  occur  in  both 
directions. 

8.4  Conferencing 

Conferencing  will  be  accomplished  by  means  of  a  multipoint  control  unit 
(MCU) .  Each  terminal  will  be  connected  to  a  port  of  the  MCU  by  a  switched 
connection  or  a  leased  circuit.  Each  connection  between  the  terminal  and  the  MCU 
is  considered  to  be  a  point-to-point  connection  as  far  as  call  connection, 
terminal  disconnection  and  call  transfer  procedures  are  concerned. 

8.3  PCM  format  conversion 

In  the  above  procedures,  no  automatic  method  for  establishing  A- law  or 
M-law  compatible  PCM  operation  was  defined. 

At  the  beginning  of  the  call,  encoding  and  decoding  by  each  terminal  is 
to  the  law  prevailing  in  its  own  region.  The  decoder  must  adapt  to  the  coding 
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law  of  the  Incoming  signals.  In  a  framed  signal  this  will  be  clear  from  the  BAS 
command;  for  unframed  audio,  signal  analysis  or  local  Icnowledge  should  be 
applied,  and  if  this  indicates  that  the  other  terminal  is  using  a  different 
coding  law  then  the  H.2A2  terminal  should  switch  both  its  encoder  and  decoder  to 
the  coding  law  of  the  other  terminal. 

In  Che  case  where  both  terminals  transmit  framed  signals,  once  the 
capability  exchange  is  completed  they  may  transmit  in  either  PCM  mode  if 
desired. 


Before  call  transfer,  in  the  case  where  both  terminals  can  transmit 
framed  audio,  the  distant  terminal's  encoder  and  decoder  must  be  forced  by  the 
relevant  BAS  capabilities  and  commands  to  the  coding  law  of  the  region  where  the 
transfer  is  to  take  place. 

9.  Procedure  for  activaiton  and  de-activation  of  data  channels 

9.1  Data  equipment  not  eonforminf  to  Recommendation  H.200/AV.270 

Each  terminal  must  transmit  a  data-rats  capability  coda  (Recommendation 
H.221}  for  each  data  rate  it  is  able  to  receive.  This  may  be  done  during  the 
capability  exchange  sequence  at  the  start  of  the  call  or  at  a  later  time  by 
initiating  a  new  capability  exchange. 

A  terminal  may  transmit  data  at  any  race  which  has  been  indicated  in 
Che  data* rate  capability  codes  it  has  received  from  the  other  terminal.  The 
appropriate  data  command  (Recommendation  H.221)  is  sent  and  in  the  following 
sub-mulciframe  the  data  transmission  is  comamnced,  occupying  the  bits  within 
each  frame  defined  in  Recommendation  H.221.  However,  at  the  time  the  data 
command  is  first  sent,  these  bits  must  be  unoccupied  or  contain  only  video 
information;  therefore  audio  or  any  ocher  signals  must  be  removed  from  this  part 
of  the  frasM  with  the  prior  transmission  of  an  appropriate  command.  In  the  case 
of  occupancy  by  video  information,  commands  are  not  available  to  reduce  the 
video  rate,  but  the  video  decoder  continues  to  operate  correctly  on  the  lower 
flow  of  information.  However,  if  the  video  rate  is  being  made  very  low  (for 
example,  less  chan  30.4  kbit/s)  or  stopped  altogether  by  the  introduction  of  a 
data  scream,  it  is  advisable  first  to  send  "freeze -picture  request" ,  followed  by 
the  video  "OFF"  command. 

The  command  "variable  LSD"  identifies  as  a  data  path  the  whole  of  the 
I -channel  capacity  not  otherwise  allocated  by  ocher  comsands;  it  must  not  be 
used  when  variable  MLP  is  on,  or  when  another  LSD  value  is  in  force.  If  used 
while  video  is  on,  video  is  excluded  from  the  I-channel. 

AC  Che  conclusion  of  the  data  transmission  the  data  "OFF"  command  is 
sent.  If  video  is  "ON"  it  will  then  occupy  the  freed  bits  in  the  next 
sub-mulciframe  and  thereafter;  otherwise  chose  bits  remain  unoccupied  until 
another  command  is  sent. 

At  any  time  during  data  transmission  the  rate  may  be  changed  by  an 
appropriate  data  command,  subject  to  the  provisions  given  above. 

Mote  -  In  Che  case  where  64  kbit/s  HSD,  for  example,  has  been  transmitted  in  the 
highest-numbered  channel  of  a  mulciple-fi  channel  connection,  a  slip  during  this 
data  transmission  would  leave  a  misalignment  when  the  HSD  is  turned  off.  To 
avoid  corruption  of  video  under  these  circumstances,  it  may  be  advisable  to 
switch  off  the  video  scream  before  sending  HSD-off,  switching  it  on  again  as 
soon  as  A  -  0  is  received  on  Che  erstwhile  data  channel. 
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9.2  Eouipaent  operating  with  an  MLP  according  to 

Recoamendatlon  H. 200/AV . 270 

Each  terminal  capable  of  operating  with  an  HLF  must  transmit  one  of  the 
ML? -capability  codes.  This  may  be  done  during  the  capability  exchange  sequence 
at  the  start  of  the  call,  or  at  a  later  time  by  Initiating  a  new  capability 
exchange . 


When  terminal  X  wishes  to  transmit  MLP,  It  transmits  ML?  "ON"  at  the 
appropriate  rate.  Receiving  the  latter,  terminal  Y  must  establish  an  MLP  channel 
at  an  appropriate  rate  (not  necessarily  the  same  rate)  In  the  retxim  direction. 

The  above  provisions  apply  equally  to  the  use  of  MLP  on  the  I -channel, 
or  in  ocher  channels  or  time-slots.  Normally  only  one  of  these  is  required; 
however  If  both  are  In  force,  with  appropriate  commands,  Chen  a  single  MLP 
sub-channel  at  the  combined  rate  may  be  Interpreted  •  this  would  be  specified 
within  Che  appropriate  service  Recommendation  (e.g.  MLP  races  of  about 
100  kblc/s  on  a  2B  call) . 

To  change  the  MLP  rate,  an  appropriate  MLP  command  Is  sent. 

To  discontinue  use  of  Che  MLP,  this  matter  may  first  be  negotiated 
within  the  MLP  Itself;  then  one  or  both  terminals  transmit  "MLP-OFF”. 

9.3  Simultaneous  transmission  of_ low- speed  data  and  MLP 

LSO  and  MLP  may  be  active  simultaneously,  provided  that  no  overlap  is 
implied  by  Che  commands  In  force;  however,  variable  LSD  and  variable  MLP  cannot 
coexist.  No  more  chan  one  LSO  channel  and  one  MLP  channel  may  be  active  at  any 
time  (see  also  section  12) . 

10.  Procedures  for  operation  of  terminals  In  restricted  networks 

Under  study;  the  following  paragraphs  give  preliminary  considerations. 

Terminals  connected  to  a  restricted  network  shall  transmit  the  BAS 
capability  "restricted"  (100) [22]  continuously  %rhen  receiving  an  Incoming  A  -  1 
at  the  start  of  a  call. 

10.1  Network  aspects 

In  this  Recommendation  the  term  "restricted  network"  applies  to  a 
network  having  restricted  64  kblt/s  transfer  capability,  defined  in 
Recommendation  1.464  as  "64  kblc/s  octet- structured  capability  with  the 
restriction  that  an  all-zero  octet  is  not  permitted”. 

10.2  Reference  connections 

10.2.1  Case  1:  56  kblt/s.  V.35  interfaces 

Figure  3a  shows  a  reference  connection  by  a  36  kblt/s  data  service 
using  V.33  interfaces.  A  36  kbic/s  clock  is  available  at  the  V.33  Interface; 

8  kHz  clock  Is  not  assumed.  Figure  3c  shows  a  reference  connection,  connected 
by  36  kbit/s  network  service  with  network  clock. 
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10.2.2  Caa«  2:  n  x  56  kbit/s.  V.35  interfaces 

Figure  Sb)  shows  a  reference  connecclon  with  more  chan  two  56  kbic/s 
connaccions.  FrasM  alignment  will  be  according  to  H.221.  Neither  septet  timing 
nor  septet  alignment  is  assumed.  Figure  5d  shows  a  multiple  n  x  36  kbit/s 
without  septet  alignment  or  septet  timing. 

10.2.3  Case  3:  n  x  ■64_  kbit/s  with  octet  timing  and  aliment 

Figure  5e)  shows  a  reference  connection  consisting  of  two  visual 
telephones  connected  by  facilities  operating  in  a  private  line  environment. 
Unrestricted  mode  of  operation  is  not  assumed. 


V.3S  CNI  CNI  V.3S 


FIGURE  Sa) 


V.35  CNI  CNI  V,35 


flGVM  5b) 

CNI  CNI 


FIGURE  5c) 

CNI  CNI  . 


FIGURE  5d) 


CNI  CNI 


FIGURE  5e)  n50l4»if 


VT:  Video  Telephone 

DSU:  Data  Service  Unit 

CNI;  Customer  Network  Interface 

DDS:  Digital  Data  Service 

PSDS;  Public  Switched  Digital  Service 
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10.2.4  Casa  4:  HQ  (384  kblt/s^  operation 

When  working  in  a  restricted  network  a  "1"  shall  be  placed  In  the 
eighth  bit  position  of  every  octet  of  every  time-slot;  the  service  channel  Is 
them  In  the  seventh  bit. 

10.2.5  Casa  5:  56  kblt/s  satellite  operation 
For  further  study. 

10.2.6  Case  6:  56  kbit/s  Interconnecting  a  64  kblt/s  network 

A  64  kblt/s  terminal  will  Interwork  with  a  56  kblt/s  terminal  as  a  rate 
adapted  data  call  over  a  64  kblt/s  bearer  channel.  The  terminal  connected  to  the 
64  kblt/s  connection  will  rate  adapt  according  to  H.221.  In  the  case  of  a 
64  kblt/s  terminal  connected  to  ISDN,  the  terminal  may  optionally  be  equipped  to 
Intercommunicate  through  an  ISON  V.3S  terminal  adaptor.  In  any  case,  becaxise  the 
56  kblt/s  terminal  cannot  transmit  correctly  aligned  septets,  the  terminal  at 
the  64  kblt/s  end  cannot  assume  septet  timing. 

10.3  Transmission  formats 

10.3.1  Framlna  signal  (56  kblt/s) 

The  transmission  shall  be  arranged  In  80  septet  frames  as  specified 

in  H.221. 

10.3.2  Transmission  formats  r56  kbit/s  operation) 

In  56  kblt/s  operation  the  septets  of  each  7  x  80  bit  frame  will  be 
transmitted  In  order,  most  significant  bit  first  at  the  56  kblt/s  rats.  Septet 
alignment  will  be  recovered  from  the  frame  alignment  signal  as  specified 
In  H.221. 


10.3.3  n  X  56  kblt/s  operation 

In  n  X  56  kblt/s  operation  each  56  kblt/s  connection  will  be  framed  and 
transmitted  separately.  Septet  timing  will  be  recovered  Independently  from  the 
frame  alignment  signal  of  each  channel,  and  the  different  delay  between  the 
channels  will  be  compensated' for  on  the  basis  of  the  aniltlframe  numbering  method 
specified  In  H.221. 

The  voice  signal  will  be  carried  In  the  Initial  connection  and  video, 
graphics  and  auxiliary  data  may  be  carried  In  the  Initial  and/or  other 
connections . 

10.3.4  n  X  HO  oneratlon 

In  n  X  HO  operation  each  connection  will  be  framed  separately  and 
differential  delay  between  the  channels  will  be  compensated  according  to  H.221. 

10.3.5  Dynamic  allocation  within  a  primary- rate  connection 

Intelligent  terminals  may  have  a  means  for  dynamically  increasing  or 
decreasing  the  bit  rate  during  a  connection.  The  means  for  controlling  these 
allocations  will  be  performed  according  to  H.221.  There  may  be  a  need  to  recover 
framing  by  extraction  from  the  received  signal  independently. 
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10.4  Interworking  becween  56  kbit/s  and  64  kbit/s  terminals 

In  the  worst  case  it  must  be  assumed  that  neither  terminal  is  aware  (by 
means  of  a  0-ehannel  message  or  otherwise)  chat  it  is  connected  to  a  terminal  of 
the  other  type;  furthermore  septet  timing  cannot  be  assumed  at  the  56  kbit/s 
end.  At  the  64  kbit/s  end,  byte  timing  is  indispensable,  since  without  this  it 
cannot  be  known  <Alch  bit  (1  in  every  8)  will  not  be  transmitted  to  the  remote 
end  (Figure  2/H.242,  outcome  IV). 

Initially,  terminal  X  (at  64  kbit/s)  transmits  FAS  and  capability-BAS 
on  bit  8,  on  the  false  assumption  that  the  remote  terminal  is  also  at  64  kbit/s. 
Frame  search  is  carried  out  on  the  whole  incoming  signal;  clearly,  searching 
only  on  bit  8  will  result  in  outcome  II  (Figure  2/H.242). 

-  If  frame  alignment  is  found,  and  this  may  be  in  any  bit  position,  given 
the  lack  of  septet  timing  at  the  other  end,  then  the  fact  of  interworking  with  a 
56  kbit/s  terminal  immediately  becomes  known  from  the  capability  BAS,  which 
terminal  Y  must  include  in  its  capability  BAS  cycle.  Terminal  X  immediately 
changes  to  transmitting  FAS  and  BAS  on  bit  7,  since  bit  8  is  the  one  which  is 
not  transmitted  through  the  restricted  networks.  Initialization  should  then 
proceed  as  in  section  6.1,  with  outcome  Ib  in  Figure  2/H.242. 

In  the  event  that  no  frame  alignment  is  found  in  any  sub-channel, 
outcome  II  of  section  6.1.1  applies. 

Note  1  -  All  56  kbit/s  audiovisual  terminals  must  transmit  the  appropriate 
capability  BAS  (100) [22]  in  every  capability  exchange. 

Note  2  •  Unless  it  is  sure  that  they  will  never  be  required  to  interwork  with 
56  kbit/s  networks,  terminals  manufactured  for  vise  on  64  kblt/s  networks  should 
preferably  have  the  capability  to  search  for  frame  alignment  in  all  bit 
positions . 

Note  3  -  It  may  be  advisable  to  mute  audio  output  until  incoming  frame  alignment 
has  been  achieved  or  a  switch  to  unframed  PCM  has  been  decided  upon. 

10.5  Interworking  between  HO  or  Hll  terminals  in.  restricted  and  unrestricted 

networks 

At  the  start  of  the  connunication,  the  terminal  on  the  restricted 
network  transmits  framed  signals  with  the  service  channel  in  bit  7  of  the 

1-channel  and  all  "l"s  in  bit  8;  the  "restricted"  capability  BAS  (100) [22]  is 

sent.  In  the  teminal  on  the  unrestricted  network,  frame  search  is  carried  out 
on  the  whole  incoming  signal  (or  incoming  TSl  if  synchronization  becween  HO/Hll 
framing  and  H.221  framing  is  maintained).  When  BAS  (100) [22]  is  detected,  a 
terminal  immediately  shifts  the  outgoing  service  channel  to  bit  7  and  sets  all 
"l"s  on  bit  8  of  every  time-slot. 

All  terminals  intended  for  interworking  with  terminals  connected  to 
restricted  networks  must  be  capable  of  performing  this  procedure. 

11.  Procedure  for  use  of  BAS -extension  codes 

Recommendation  H.221  provides  for  the  attribute  (111)  for  extension  of 
the  use  of  the  BAS  position  in  the  subsequent  sub-multiframe(s)  for  other 
purposes.  There  are  32  values  of  this  attribute,  the  meanings  of  these  being 
defined  in  H.221. 
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Note  that  the  value  (III) [24]  is  the  capability  marker  (see  section  2) 
which  is  followed  by  normal  BAS  codes,  not  by  any  escape  values. 

Value  (O'lS)  are  reserved  for  future  extension  of  the  scheme  to  include 
attribute  class  and  family. 

Values  [16-23]  are  defined  as  single-byte  extension  (SBE);  codes  of  SBE 
type  may  be  transmitted  at  any  time  and  to  any  terminal. 

Value  [18]  gives  access  to  a  cable  of  values  specifying  applications  of 
a  data  channel  (LSD  or  HSD) .  The  application  is  active  from  the  sub-mulciframe 
following  Chat  in  which  the  relevant  specific  application  command  BAS  is 
transmitted.  The  closure  of  the  data  channel  (using  LSD/HSD-off)  effectively 
closes  Che  application. 

All  terminals  must  recognize  the  SBE  attributes,  at  least  to  the  extent 
of  ignoring  the  subsequent  code,  whose  meaning  is  not  prescribed  in  this 
Recommendation.  However,  when  (111) [17]  is  received,  the  subsequent  code  may  be 
one  of  the  mandatory  values  specified  in  Recommendation  H.230.  The  ability  of  a 
terminal  to  use  Che  concent  of  ocher  such  codes  is  governed  by  other 
Recommendations.  For  example,  Recommendation  H.320  defines  the  requirements  for 
visual  telephone  terminals  to  act  upon  some  of  the  control  and  indication 
values . 


Values  [25-31]  are  of  multiple  byte  extension  (HBE) ;  codes  of  MBE  may 
only  be  transmitted  to  a  terminal  which  has  previously  indicated  its  capability 
CO  receive  MBE.  It  follows  that  a  "non-CCITT  capabilities”  message  may  not  be 
transmitted  in  the  initial  capability  exchange,  until  the  MPE-cap  has  been 
received.  An  example  of  the  structure  of  MBE  messages  is  given  in  Appendix  3. 

12.  Bit  occupancy  and  the  sequencing  of  BAS  codes 

In  general,  when  there  is  no  set  procedure  governing  Che  sequence  of 
BAS  codes,  priorities  may  be  determined  by  the  sending  terminal.  When  there  is 
no  ocher  demand  for  use  of  the  BAS  position,  it  is  advisable  to  cycle  through 
all  the  valid  BAS  commands,  so  chat  in  the  event  of  a  temporary  disturbance  the 
proper  mode  will  be  restored  as  soon  as  possible  thereafter. 

Table  1/H.242  summarizes  the  BAS  capabilities  that  can  be 
simultaneously  valid. 
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TABLE  1/H.242 
Capability  aummArv 


Audio : 

one  or  more  valuas  from  A- law,  ^-law, 
G.725-T1,  G.725-T2,  Au-16  kbic/s,  Au-ISO 

Video; 

absent,  qx.  (QCIF  plus  one  MFI  value),  or 
(OCIF  +  GIF  oltia  two  MPI  values) .  and/or 
video -ISO  and/or  AV*ISO 

Transfer  race: 

absent  (meaning  rate  -  64  kbit/s  only* 

££  up  Co  four  values:  max.  no.  of  64, 

384  kbit/s  channels,  1536,  1920  kbiC/s; 

{128,  192,  256,  512,  768,  1152, 

1472  kbit/s) 

Restricted  network; 

absent  ^  present 

Low* speed  data  (LSO) : 

absent  all  relevant  values 

High-speed  data  (HSD) : 

absent  qx.  relevant  values 

Low*  speed  MLF : 

absent  jjX  *11  relevant  values 

High-speed  MLP: 

absent  ^  all  relevant  values 

Applications  in  data  channel: 

absent  qx  *11  relevant  values 

Encryption: 

absent  sx  present 

Multiple-byte  extension: 

absent  sx  present 

*  When  reducing  the  transfer- rate  capability  to  64  kbit/s  from  a  higher  value, 
the  value  "transfer-cap  -  64  kbit/s"  ntust  be  included. 

The  capability  sot  consists  of  the  capability  market  (111) [24]  followed 
by  all  currently  valid  valuas,  in  any  order;  this  may  in  turn  be  followed  by  a 
repetition  of  the  set,  or  by  the  marker  alone  to  indicate  completion  of  the  set 
prior  to  sending  commands.  No  values  should  be  repeated  within  a  set.  If  it  is 
desired  to  change  the  capability  set  during  its  transmission,  the  existing  set 
must  first  be  completed  without  change,  followed  by  the  marker  alone  and  at 
least  one  BAS  command  before  the  new,  changed  sec  is  started. 

Table  2/H.242  summarizes  the  BAS  commands  that  can  be  simultaneously 

valid. 
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TABLE  2/H.242 

Command  aunmiArv 


Attribute 

Alternative  values 
(last  value  only  is  valid) 

Default 

assumed 

Comments 

Audio  (000) 

[0,  4-7,  13-19,  24-31] 

[18  or  19] 

Transfer 

[0-15,  23,  24.  26.  29] 

[0] 

rate  (001) 

[17] 

see  section  7.2.3 

[18-22] 

additional  channels  only 

Video  and 

[0-4] 

[0] 

other  (010) 

[6.  7] 

[7] 

[16] 

cancelled  by  command  in  video  frame 

[17] 

expires  after  fast  update  completed 

[18,  21] 

[21] 

[19.  21] 

[21] 

[20.  21] 

[21] 

[25.  26] 

[26] 

[27,  28] 

[28] 

LSD  and 

[0-15.  31] 

[0] 

MLP  (011) 

[16-19] 

[16] 

HSO  and 

[0,  17-22] 

[0] 

escape  table  (111) [16] 

H-MLP 

[2-8,  13.  14] 

[14] 

Only  one  valua  in  each  row  can  ba  In  forca  at  any  ona  Instant,  up  to 
17  valuas  on  tha  Initial  channal  (all  tha  abova  valuas  axcapt  (001)[18*22]  apply 
only  to  the  initial  channal) ;  howavar  in  practica  many  of  tha  combinations  ara 
precludad  by  tha  fact  that  thay  would  affact  tha  sama  bits  of  tha  channal  (for 
example,  (Oil) [31]  and  (Oil) [19]  cannot  coexist). 

A  command  remains  in  forca  until  another  from  tha  same  row  is 
transmitted.  A  command  must  not  ba  transmitted  if  to  obey  it  would  causa  a 
simultaneous  mode  change  on  another  row;  in  such  a  casa  the  other  row  value  must 
be  changed  first  (for  this  purpose,  a  change  of  bit -rate  of  video  or  any  of  the 
variable  data  valuas  does  not  constitute  a  mode  change) . 

In  general,  unless  specified  otherwise,  a  BAS  code  which  is  invalid  or 
which  contravenes  the  provisions  of  this  cable,  or  otherwise  indicates  an 
impossible  frame  structure  or  system  status,  must  not  be  transmitted. 

The  following  notes  serve  to  clarify  the  application  of  these  rules  to 
Che  multiplexing  of  audio,  video  and  Che  various  forms  of  data.  Some  examples 
relacing  Co  data  cransmission  are  given  in  Appendix  5. 
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a)  Audio  cannot  penetrate  into  fixed  rate  Data  (LSD  or  ML?)  bit 
positions.  It  can  expand  its  capacity  into  vacant  or  video  or  variable  data  bit 
positions.  It  can  reduce  its  capacity  within  the  audio  bit  positions  currently 
occupied. 


b)  Video  occupies  all  bit  positions  which  are  not  assigned  by  other 
comnands  (ECS,  Audio,  LSD/MLP  regardless  of  being  fixed  rate  or  variable  rate). 

Video  can  be  turned  on  at  anv  time  even  if  the  available  capacity  for 
video  is  zero  at  the  corresponding  aub-multiframe :  (it  may  happen,  for  example, 
that  video  is  switched  on  Just  before  the  variable  rate  LSD  or  MLF  channel  is 
closed);  the  decoder  must  not  ignore  "video  on"  even  in  this  case,  otherwise  a 
mode  mismatch  occurs.  However,  if  video  capacity  is  less  than  about  30  kbit/s 
averaged  over  several  sub-multlframes ,  it  may  not  be  practical. 

It  should  be  noted  chat  video-off,  (010) [0],  is  preferably  preceded  by 
freeze -picture  request,  (010) [16]. 

c)  Fixed  rate  LSD/MLP  cannot  penetrate  into  Audio  bit  positions  nor 
into  fixed  rate  MLP/LSD  bit  positions.  It  can  expand  its  capacity  into  vacant  or 
video  or  variable  MLP/LSD  bit  positions.  It  can  reduce  its  capacity  within  the 
data  bit  positions  currently  occupied.  As  a  combination,  fixed  rate  LSD/MIf  can 
occupy  new  bit  positions  which  have  previously  been  either  vacant,  video, 
variable  rate  MLP/LSD  or  occupied  by  the  same  type  of  fixed  rate  data. 

d)  Variable  rate  LSD/MLP  occupies  all  bit  positions  which  are  not 
assigned  by  other  fixed  rate  commands  (ECS,  Audio,  fixed  rate  MLP/LSD).  If  video 
has  been  on,  it  is  excluded  when  variable  rate  LSD  or  MLP  is  turned  on.  If 
variable  rate  LSD/MLP  has  been  on,  opening  a  variable  race  MLP/LSD  channel 
should  be  preceded  by  closing  the  existing  variable  race  LSD/MLP  channel. 

Variable  rate  LSD  or  MLP  can  be  turned  on  at  anv  time  even  if  the 
available  capacity  for  it  is  zero  at  the  corresponding  sub-multiframe:  (it  may 
happen,  for  example,  that  the  variable  MLP  is  switched  on  Just  before  closing 
the  LSD  channel  which  has  been  occupying  all  the  capacity  ocher  chan  audio) ;  the 
decoder  must  not  Ignore  "variable  rate  LSD  or  MLP  on"  even  in  this  case, 
otherwise  a  mode  mismatch  occurs. 

e)  LSD/MLP  rate  may  be  changed  without  first  closing  the  data 
channel  -  this  applies  equally  to  changes  between  fixed  and  variable  race.  It  is 
emphasized  chat  there  can  only  be  one  LSD  and  one  MLP  channel  at  any  instant. 

f)  Capacity  of  video  or  variable  LSD/MLP  can  be  temporarily  reduced 
to  zero  in  a  sub-multiframe  as  part  of  dynamic  bit  rate  allocations.  It  is 
impractical,  however,  if  that  situation  continues  for  a  long  time. 

g)  The  rules  for  the  use  of  HSD  and  H-MLP  (in  other  than  the 
I-channel)  are  identical  to  chose  given  above  for  LSD  and  MLP  in  the  I-channel. 

13.  Procedure  for  dealing  with  6B-H0  interconnection 

For  further  study. 
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U.  Procedure  for  use  of  encryption  control  signal  channel 

Each  teminal  must  transmit  the  encryption  capability  code  if  it  is 
able  to  handle  the  ECS  channel.  No  terminal  may  activate  the  channel  without 
first  receiving  the  corresponding  capability  code.  Once  an  ECS  capability  code 
has  been  transmitted  it  cannot  be  cancelled  by  omission  from  a  subsequent 
capability  exchange.  That  is  to  say,  a  terminal  having  once  received,  stored  and 
made  use  of  an  ECS  capability  code  should  assume  continued  validity  until 
cancelled  by  the  local  user.  Thus  encryption  can  be  discontinued  by  the  users 
themselves  but  not  by  a  third  party  tampering  with  the  BAS -capability  exchange. 

The  initiating  terminal  transmits  the  command  "ECS  Channel  ON":  from 
the  next  multiframe  it  opens  the  800  bit/s  ECS  channel  defined  in 
Recommendation  H.221,  whose  use  is  specified  in  the  Recommendation  defining  the 
en»-rypcion  system  (FAS,  BAS  and  the  ECS  channel  itself  are  in  any  case  not 
encrypted) . 

When  encryption  has  been  turned  off,  the  BAS  command  "ECS  channel  OFF" 
is  used  to  close  the  ECS  channel. 
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APPENDIX  I 

(to  RecommandAtlon  H.2A2) 

InlclallzAClon:  Casa  o£  Videophone  to  Recommendation  H.320,  Type  Xb3 

Underlined  letters  In  the  comments  column  correspond  to  points  in  the 
associated  Figure  Al. 

SUCCZSSIVr  SUB-HULIiniAMZS  AT  TZIMIHAL  "X*  ORLX 

TRARSMITTKD  XZCZIVZO 


FAS, 

A-blt 

BAS 

Attr. 

Vtiua 

Audio 

aodo 

Vldao 

rata 

FAS. 

A-bit 

BAS 

Attr. 

Audio 

fflodo 

Vidoo 

roto 

Coaaanta 

zx 

ZX 

XX 

zz 

zz 

XX 

XX 

XX 

XX 

XX 

Ld. 

(ill) 

till 

0 

(off) 

XX 

XX 

XX 

XX 

XX 

4  eap-aazk 

F,1 

(100) 

C21 

0 

(off) 

XX 

XX 

XX 

XX 

XX 

audio  BAS'cap 

F.l 

(100) 

til 

0 

(0<fl 

XX 

XX 

XX 

XX 

XX 

audio  BAS-eap 

F.l 

(101) 

(ZRl 

0 

(off) 

XX 

XX 

XX 

XX 

XX 

video  Cap-QCIF 

F.l 

(101) 

till 

0 

(off) 

XX 

XX 

XX 

XX 

XX 

HPI  3/29.97 

F.l 

(100) 

till 

0 

(off) 

XX 

XX 

XX 

XX 

XX 

Teanafar  rata  Cap  2B 

F.l 

(111) 

(2*1 

0 

(off) 

XX 

XX 

XX 

XX 

XX 

zepaat  eap'aet 

F.l 

(100) 

(31 

0 

(off) 

XX 

XX 

XX 

XX 

XX 

(eeatlau*  to 

erelo  capo) 

(aaazeblas  for  fzaea  aligaeoat) 

about  oaa  tzaaait? 

F.l 

(101) 

[2*1 

0 

(off) 

zz 

zz 

zz 

zz 

zz 

F.l 

(100) 

(171 

0 

(off) 

Id 

(1111 

(Zil 

0 

(off) 

R  iaeoeiag  eap***t 

F.l 

(111) 

(2*1 

0 

(off) 

F.l 

(100) 

[11 

0 

(eft) 

. . . 

F.l 

(100) 

(31 

0 

(off) 

F.l 

(100) 

til 

0 

(off) 

F.l 

(100) 

t*l 

0 

(off) 

F.l 

(101) 

(SRI 

0 

(off) 

F.l 

(101) 

[201 

0 

(off) 

F.l 

(101) 

(2il 

0 

(off) 

F.l 

(101) 

(2*1 

0 

(off) 

F.l 

(100) 

fill 

0 

(off) 

F.l 

(100) 

(171 

0 

(off) 

F.l 

(111) 

(2*1 

0 

(off) 

cap'zat  coBplata 

.  . . 

.  . . 

(aaazehias  for 

otultlfz 

up  to  320  aa 

F.2 

(101) 

[2*1 

0 

(off) 

F.l 

(100) 

(17) 

0 

(off) 

R  afa  achiavad,  A>0 

F.O 

(100) 

[171 

0 

(off) 

F.l 

(111) 

(2*1 

0 

(off) 

F.O 

(100) 

(171 

0 

(off) 

(waitias 

F.l 

for  iaeoelas 

(111)  [3*1 

A-O) 

0 

(oft) 

F.O 

(111) 

[2*1 

0 

(off) 

F.l 

(100) 

(31 

0 

(off) 

R  iaeoains  A'O 

F.O 

(100) 

(31 

0 

(off) 

F.O 

(100) 

(*1 

0 

(off) 

F.O 

(100) 

(41 

0 

(off) 

F.O 

(101) 

(20) 

0 

(off) 

F.O 

(101) 

(aei 

0 

(off) 

F.O 

(101) 

(3*1 

0 

(oft) 

F.O 

(101) 

(341 

0 

(off) 

F.O 

(100) 

(17) 

0 

(oft) 

F.O 

(100) 

(X7) 

0 

(off) 

F.O 

(111) 

(2*1 

0 

(off) 

F.O 

(111) 

(341 

0 

(off) 

F.O 

(100) 

(5) 

0 

(off) 

cap'tat  coaplata 

F.O 

(2fla,) 

(211 

0 

(off) 

F.O 

(100) 

(*1 

0 

(oft) 

R  atact  aoda  switch 

F.O 

(aiR) 

(11 

1 

(off) 

F.O 

(101) 

(201 

0 

(off) 

(Beta  1) 

F.O 

(000) 

(391 

7 

ild 

F.O 

(101) 

(2*1 

0 

(off) 

F.O 

(010) 

(11 

7 

*S.  * 

F.O 

(100) 

(17) 

0 

(off) 

F,0 

(000) 

[291 

7 

*6.  * 

F.O 

(111) 

(2*1 

0 

(off) 

F.O 

(010) 

(11 

7 

*8.* 

F.O 

(100) 

(3) 

0 

(oft) 
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(waltlns  tor  Ineoalng  aed*  ehaataa) 


P.O 

(010) 

Ill 

7 

*6.4 

P.O  (101) 

[24] 

0 

(off) 

P.o 

(000) 

(2S1 

7 

46.4 

P.O  (000) 

[2i1 

0 

(off)  1  laeoalag  switch 

P.O 

(010) 

Cl] 

7 

46.4 

P.O  (010) 

til 

7 

(off)  10  kblt/s  audio 

p.o 

(000) 

(291 

7 

46.4 

P.O  (000) 

[20] 

7 

46 . 4  vldoo  09 

p.o 

(010) 

Cl] 

7 

46.4 

P.O  (010) 

[1] 

7 

40.4  Eopaat  valid 

p.o 

(000) 

[29] 

7 

46.4 

P.O  (000) 

[20] 

7 

46.4  eoaa&ada 

(BOW  daal.  with  laeoad 

B- 

ehaaaal 

oaea  eoaaaetioa 

la  eeaplatad) 

PE.  01 

(010) 

(11 

7 

46.4 

Pa.Oj  (000) 

[29] 

7 

40.4  2 

PP.Ol 

(000) 

[29] 

7 

46.4 

Ps.Ox  (010) 

[1] 

7 

40.4 

.  .  . 

(aaarehlBB  Eos  fiaaa  allgaaaat 

oa  ehaaaal  #2) 

PP.Ol 

(010) 

[11 

7 

46.4 

PE. 01  (000) 

[29] 

7 

40.4  g  allga.  raeovarad 

PP.Ol 

(000) 

[29] 

7 

46.4 

PP.Ol  (010) 

[1] 

7 

40.4 

(ClBdta6  aultlfxaaa  allgaaaat 

aad  buffaxlag  to  syaebeoalsa) 

pp.oa 

(010) 

[1] 

7 

46.4 

PP.Ol  (000) 

(291 

7 

46.4  2  aaad  A^O  oa  ehaa.  #2 

PP.OO 

(000) 

[29] 

7 

46.4 

PP.Ol  (010) 

Ill 

7 

46.4 

(waltlag  tor  laeealag  A2~0) 

PP.OO 

(010) 

[11 

7 

46.4 

PP.02  (000) 

[29] 

7 

46.4  2  laeoalBO  Aj'O 

PP.OO 

(m> 

til 

7 

46.4 

PP.OO  (010) 

[1] 

7 

40.4  atart  aoda  awlteh  to 

PP.OO 

(001) 

[1] 

7 

106.6 

PP.OO  (000) 

[20] 

7 

40.4  azpaad  vldoo  (>ota  1) 

PP.OO 

(010) 

[11 

7 

106.8 

PP.OO  (010) 

(11 

7 

46.4 

PP.OO 

(000) 

[29] 

7 

106.8 

PP.OO  (000) 

[29] 

7 

46.4 

PP.OO 

(001) 

[1] 

7 

108.8 

PP.OO  (010) 

[1] 

7 

40.4 

(eoBtlaua 

to  eyela 

BAS 

eoaaaada)  (waltlas  tos 

laeoalag 

aoda 

ehaagaa) 

PP.OO 

(010) 

[11 

7 

106.8 

PP.OO  (OOP 

(11 

7 

40.4  g  laeoalag  aoda  aw. 

PP.OO 

(000) 

[29] 

7 

106.6 

PP.OO  (OOP 

[1] 

7 

106. B 

(Inltlaliaattoa  eoaplatad) 


Note  1  •  The  modes  selected  for  switching  are  governed  by  "terBlnal  procedures” 
which  in  general  depend  on  the  application;  in  the  present  case  of  videophone 
service,  the  procedure  is  specified  in  Recommendation  H.320. 
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TERMINAL  "X” 
Start  conanunication  A 


searching  for  FAS 


detect  FAS 
store  BAS  cap. -set 
recover  HFA 


detect  A  a  0  send 
one  more  cap. -set 
send  mode  svitch 


switch  receive  mode  p 

"o 


searching  for  FAS  //2 


detect  FAS  //2 

recover  MFA  #2  and 
buffer  to  synch, 
with  initial 
channel  . . .  completed 

detect  A2  ■  0 
send  mode  switch 


decode  108.8  kbit/s  ^ 
video 


TERMINAL  "Y" 


start  (a  little  later) 
searching  for  FAS 

-  detect  FAS 

store  BAS  cap. -set 

-  recover  MFA 


detect  A  a  0.  send  one 
more  cap.  -set 


-  send  mode -switch 


-  switch  receive  mode 


searching  for  FAS  02 

-  detect  FAS  02 

-  recover  MFA  and  synch. 


detect  A  a  0 
send  mode  switch 

decode  108.8  kbit/s 
video 


FIGURE  Al/H.242 


CCITT\COMXV\HAPP\R037E3A  TXS 


-  73  - 

COM  XV-R  37-E 

APPENDIX  II 

(CO  Reconusondacion  H.242) 

Moda-0  forcing;  Casa  of  Vidaophona  co  Racoismandaclon  H.320,  Typa  Xb3 


Undarllnad  laccars  in  cha  commancs  column  correspond  co  points  in  Che 
associacad  Figure  A2.  * 

successive  sui-MOLTznuuas  at  reiiMiRAi.  -x*  oslt 

TAAiisHitTeo  aeceiveo 


PAS. 

BAS 

Audio 

Video 

FAS. 

BAS 

Audio 

Vidao 

Coaaaata 

A'blt 

Attr . 

Value 

■oda 

rftt* 

A-bit 

Attr. 

Value 

•ode 

roto 

PF.OO 

(010) 

[11 

7 

107.6 

FF.OO 

(000) 

(201 

7 

107.6 

Video  la  OB  (B.261) 

FP.OO 

(000) 

(201 

7 

107.6 

FF.OO 

(ooi; 

(1) 

7 

107.8 

Audio  la  16  Icbit/a 

FF.OO 

(001) 

(11 

7 

107.6 

FF.OO 

(Oil) 

(2) 

7 

107.6 

TraBatac  rata  ia  2  z  64 

FF.OO 

(Oil) 

(21 

7 

107.6 

FF.OO 

(010) 

(1) 

7 

107.6 

Data  la  OB  at  1.2  kbit/a 

FF.OO 

(010) 

(11 

7 

107.6 

FF.OO 

(000) 

(291 

7 

107.6 

FF.OO 

(211) 

(21 

7 

107.6 

FF.OO 

(001) 

(11 

7 

107.6 

2  Data  to  60  of£ 

FF.OO 

(2iR) 

(21 

7 

106.6 

FF.OO 

(Oil) 

(21 

7 

107.6 

Vidao  to  60  att 

FF.OO 

(2Ri) 

(21 

7 

(a££) 

FF.OO 

(010) 

(11 

7 

107.6 

Txaaafar  rata  64  kbit/a 

FF.OO 

(000) 

(121 

7 

att 

FF.OO 

(000) 

(291 

7 

107.6 

Audio  A*la»,  OP 

FF.OO 

(000) 

(ISI 

32 

att 

FF.OO 

(001) 

(11 

7 

107.6 

FF.OO 

(010) 

(01 

OF 

att 

FF.OO 

(Oil) 

(21 

7 

107.6 

FF.OO 

(000) 

(101 

OP 

att 

FF.OO 

(010) 

(11 

7 

107.6 

FF.OO 

(UI> 

(2il 

OF 

att 

FF.OO 

(000) 

(291 

7 

107.6 

g  cap  eark 

FF.OO 

(i2a> 

(121 

OP 

att 

FP.OO 

(001) 

(11 

7 

107.6 

64  kbit/a*eap  oaly 

FF.OO 

(122) 

(11 

OP 

att 

FP.OO 

(Oil) 

(21 

7 

107.6 

A'law  capability  oaly 

FF.OO 

(111) 

(lil 

OP 

att 

FF.OO 

(010) 

(11 

7 

107.6 

eap-eark 

(eontinua  to 

eyela 

tbaao  eapa) 

(awaitins  ineoalaa  i 

Bade  ebaasa  aad  cap.  aat) 

FF.OO 

(100) 

(161 

OP 

att 

FF.OO 

(000) 

(291 

7 

107.6 

FF.OO 

(100) 

(11 

OP 

att 

FF.OO 

(211) 

(21 

7 

107.6 

2  laeae-  data  to  60  att 

FF.OO 

(111) 

12a) 

OP 

att 

FF.OO 

(212) 

(2) 

7 

108.6 

FF.OO 

(100) 

(161 

OP 

att 

FF.OO 

(221) 

121 

7 

(SU) 

laeoeiBA  ehaa.  #2  att 

FF.OO 

(100) 

(11 

OP 

att 

FF.OO 

(222) 

(III 

7 

(oft) 

lacoaiaa  audio  to  ba  OF 

FF.OO 

(010) 

(0) 

OP 

att 

FF.OO 

(111) 

(24) 

OP 

att 

FF.OO 

(001) 

[01 

OP 

att 

FF.OO 

(100) 

(31 

OP 

att 

FF.OO 

(000) 

(161 

OP 

att 

FF.OO 

(100) 

(41 

OF 

att 

FF.OO 

(Oil) 

(0) 

OP 

att 

FF.OO 

(101) 

(20) 

OF 

att 

FF.OO 

(010) 

(01 

OP 

att 

FF.OO 

(101) 

(24) 

OF 

att 

FF.OO 

(001) 

(01 

OP 

att 

FF.OO 

(100) 

(17) 

OF 

att 

FF.OO 

(000) 

(101 

OP 

att 

FF.OO 

(111) 

(24) 

OF 

att 

(«ontlnu«  to  cyelo  all  valid  BAS  cooBanda) 


The  moda-0  forcing  procedure  is  noc  complaca;  subsequent  action  depends 
on  the  "terminal  procedure”,  according  co  the  reason  for  performing  the  switch 
CO  mode  zero. 
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TERMINAL  ”X' 
switch  to  Mod* 

s*nd  cap.-s*t 


OF 


TERMINAL  'T* 


switch  receive  mode 

detect  reduced  capability 
send  mod*  switch 
send  cap. -set 
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APPENDIX  III 

(to  Recommen<latlon  H.242) 


1. 


(Ill)  [74]  Cap*mark 

(100)  [4]  Audio  Typo  2  (G.722,  56  kbit/s) 

(100)  [17]  2  X  64  kbit/s  transfer  rate 

(101)  [21]  CIF  video  capability 

(101)  [22]  1/29.97  MPI  for  QCIF 

(101)  [23]  2/29.97  MPI  for  CIF 

(101)  [31]  MBE-cap 

(111)  [16]  Set  to  escape  cable  for  HSD 
(101)  [17]  64  kbit/s  HSD-cap 

(111)  [24]  Cap-mark,  repetition  of  capability  set 

(100)  [4]  Audio  Type  2  (G.722.  56  kbit/s) 


decode  incoming  BAS  capabilities: 
these  include  (101) [31],  so  remote 
end  can  handle  M£E  codes 


3. 


(Ill)  [24]  Cap -mark 

(100)  [4]  Audio  Type  2  (G.722,  56  kbit/s) 

(100)  [17]  2  X  64  kbit/s  transfer  rate 

(101)  [21]  CIF  video  capability 

(101)  [22]  1/29.97  MPI  for  QCIF 

(101)  [23]  2/29.97  MPI  for  CIF 

(101)  [31]  MBE-cap 

(111)  [16]  Set  to  escape  table  for  HSD 
(101)  [17]  64  kbit/s  HSD-cap 

(111)  [30]  Start  of  non-CCZTT  capability  message 

(N)  Infomatlon  will  be  M  bytes 

(byte  1}  Country  coda  according  to  ReconBendation  T.3S 

(byte  2)  Country  code 

(bytes  3,4)  Manufacturer  code  (Company  XYZ) 

(bytas  5-M}  Type  identity 

(111)  [24]  Cap-mark,  repetition  of  capability  set 

(100)  [4]  Audio  Type  2  (G.722.  56  kbit/s) 

incoming  capability  cycle  now 
includes  the  same  non-standard  mode 


(111)  [30]  Start  of  non-CCITT  command  message 

(N)  Information  will  be  N  bytes 

(byte  1}  Country  code  according  to  Recommendation  T.35 

(byte  2)  Country  Code 

(bytes  3,4}  Manufacturer  code  (Company  XY2) 

(bytes  5-N)  Type  identity 


The  mode  switch  is  effective  from  the  sub -multiframe  following  that 
containing  byte  N. 
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APPENDIX  IV 

(CO  RecommendaCton  H.242) 

Exanaloa  of  avniniotrleal  and  unsvnmotrlcal  Cransmission  modaa 


a)  Example  of  gvnmatrlcal  transmission  mode 


Audio 

Video 

Transfer 

rate 

LSD 

HSD 

MLP 

Capabilities  o£  Terminal  X 

16  kbit/s 

Yes 

IB 

1.2  kbit/s 

- 

No 

Capabilities  of  Terminal  Y 

Type  2 
+16  kbit/s 

Yes 

2B 

1.2  kbit/s 

Yes 

Mode  in  X-co>Y  direction 

16  kbit/s 

ON 

IB 

1.2  kblc/s 

- 

OFF 

Mode  in  Y-to-X  direction 

16  kbit/s 

ON 

IB 

1.2  kbic/s 

- 

OFF 

b)  Example  of  unsvmmatrical  transmission  mode 

Audio 

Video 

Transfer 

rate 

LSD 

HSD 

MLP 

Capabilities  of  Terminal  X 

PCM 

Yes 

2B 

1.2  kbit/s 

No 

No 

Capabilities  of  Terminal  Y 

16  kbiC/s 

No 

2B 

56  kbiC/s 

No 

No 

Mode  in  X>co*Y  direction 

OFF 

OFF 

2B 

56  kbit/s 

- 

OFF 

Mode  in  Y-Co-X  direction 

OFF 

ON 

2B 

1.2  kbic/s 

- 

OFF 
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APPENDIX  V 

(CO  ReconunendaCion  H.2A2) 


4k  1200  LSD-4. 8k/6.4k/14. 4k  and  ovar,  MLP-6.4k 

4k  8k  Au-S6k,  LSD-4 . 8k/6 . 4k/14 . 4k  and  over 

4k  var  LSD-4. 8k/6.4k/14. 4k  and  over,  MLP-var 

6.4*k  8k  Au-56k.  #,  LSD-300/1200/4. 8k/6.4k/9.6k/14. 4k  and  over 

var  1200  LSD-16k  and  over/var,  MLP-6.4k 

var  6.4k  #,  LSD-16k  and  over/var,  MLP-4k/6.4k 

var  9.6k  Au-56k,  #,  LSD-16k  and  over/var,  MLP-6.4k 


(exenple) 


4k  300  LSD-4. 8k/6.4k/14.4k/48k  and  over,  MLP-6.4k 

4k  8k  Au-S6k,  LSD-4 . 8k/6 . 4k/14 . 4k/48k  and  over 

4k  16k  Au-48k/56k,  #,  LSD-4 . 8k/6 . 4k/14 . 4k/48k  and  over 

4k  var  #,  LSD-4 . 8k/6 . 4k/14 . 4k/48k  and  over,  MLP-var 

6.4*k  8k  Au-56k.  LSD-300/1200/4. 8k/6.4k/9.6k/14.4k/48k  and  over 

6.4*k  40k  Au-48k/56k.  #.  LSD-300/1200/4 . 8k/6 . 4k/9 . 6k/14 . 4k/48k  and  over 

var  4.8k  #,  LSD-48k  and  over/var,  MLP-4k/6.4k 

var  9.6k  Au-S6k,  #,  LSD-48k  and  over/var,  MLP-6.4k 

var  16k  Au-48k/S6k,  #,  LSD-48k  and  over/var 


4k  1200  LSD-4. 8k/6.4k/14.4k/48k  and  over,  MLP-6.4k 

4k  8k  Au-S6k,  LSD-4. 8k/6 .4k/14.4k/48k  and  over 

6.4*k  8k  Au-56k,  LSD-300/1200/4 . 8k/6 . 4k/9 . 6k/14 . 4k/48k  and  over 


"vldeo'on”  oay  not  be  praecical  in  these  cases. 
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(example) 


var  1200  LSD-16k  and  over/var,  MLP-6.4k 

var  4.8k  LSI>>16k  and  over/var,  MLP-4k/6.4k 

var  9.6k  Auo56k,  LSD-I6k  and  over/var,  MLP-6.4k 

^k  8k  Au-56k,  LSD-4 . 8k/6 . 4k/14 . 4k/16k  and  over 


var  1200  LSD-48k  and  over/var,  MLP-6.4k 

var  4.8k  LSD-48k  and  over/var,  MLP4k/6.4k 

var  8k  Au-S6k,  LSD-48k  and  over/var 

var  16k  Au-48k/56k,  LSD-48k  and  ovar/var 

4k  8k  Au-S6k,  LSD-4. 8k/6.4k/14.4k/48k  and  over 


*  These  rates  are  reduced  by  800  blt/s  when  the  ECS  is  active, 
"video  on"  may  not  be  practical  in  these  cases. 
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Recommendation  H.26I 

VIDEO  CODEC  FOR  AUDIOVISUAL  SERVICES  AT  p  x  64  kbit/s 
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The  CCITT, 


(a)  that 
videoconference  and 


there  is  significant  customer  demand  for  videophone, 
other  audiovisual  sei;yices; 


(b)  that  circuits  to  meet  this  demand  can  be  provided  by  digital 
transmission  using  the  B,  HO  rates  or  their  multiples  up  to  the  primary  rate  or 
H11/H12  rates; 


(c)  that  ISDNs  are  likely  to  be  available  in  some  countries  that 
provide  a  switched  transmission  service  at  the  B,  HO  or  H11/H12  rate; 

(d)  that  the  existence  of  different  digital  hierarchies  and  different 
television  standards  in  different  parts  of  the  world  complicates  the  problems  of 
specifying  coding  and  transmission  standards  for  international  connections; 

(e)  that  a  number  of  audiovisual  services  are  likely  to  appear  using 
basic  and  primairy  race  ISON  accesses  and  chat  some  means  of  intercommunication 
among  these  terminals  should  be  possible; 

(f)  Chat  Che  video  codec  provides  an  essential  element  of  the 
infrastructure  for  audiovisual  services  which  allows  such  intercommunication  in 
Che  framework  of  Recommendation  H.200; 

(g)  chat  Recommendation  H.120  for  videoconferencing  using  primary 
digital  group  transmission  was  the  first  in  an  evolving  series  of 
Recommendations , 

appreciating 

that  advances  have  been  made  in  research  and  development  of  video 
coding  and  bit  rate  reduction  techniques  which  lead  to  the  use  of  lower  bit 
races  down  to  64  kbic/s  so  Chat  this  may  be  considered  as  the  second  in  the 
evolving  series  of  Recommendations, 

and  noting 

chat  it  is  the  basic  objective  of  the  CCITT  to  recommend  unique 
solutions  for  international  connections, 

recommends 

that  in  addition  to  chose  codecs  complying  to  Recommendation  H.120, 
codecs  having  signal  processing  and  transmission  coding  characteristics 
described  below  should  be  used  for  international  audiovisual  services . 


Note  1  -  Codecs  of  this  type  are  also  suitable  for  some  television  services 
where  full  broadcast  quality  is  not  required. 

Note  2  -  Equipment  for  transcoding  from  and  to  codecs  according  to 
Recommendation  H.120  is  under  study. 
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1 .  Scope 

This  Recommendation  describes  the  video  coding  and  decoding  methods  for 
the  moving  picture  component  of  audiovisual  services  at  the  rates  of 
p  X  64  kbit/s,  where  p  is  in  the  range  1  to  30. 

2.  Brief  specification 

An  outline  block  diagram  of  the  codec  is  given  in  Figure  1/H.261. 


Video 

signal 


EXTERNAL 

CONTROL 


i 


CODING  CONTROL 


SOURCE 

- 

VIDEO 

TRAN5MISS2DN 

'mA^6MISSI0N 

1 

CODER 

BUFFER 

CODER 

a)  Video  Coder 


SOURCE 

VIDEO 

MULTIPLEX 

RECEIVING 

mNSlISSICN 

DECODER 

DECODER 

BUFFER 

DECODER 

Coded 
bit  stream 


b)  Video  Decoder 


T1502430-90 


FIGURE  1/H.261 

Outline  block  diagram  of  the  video  codec 

2.1  Video  input  and  output 

To  permit  a  single  Recommendation  to  cover  use  in  and  between  regions 
using  625-  and  525-line  television  standards,  the  source  coder  operates  on 
pictures  based  on  a  common  intermediate  format  (GIF) .  The  standards  of  the  input 
and  output  television  signals,  which  may,  for  example,  be  composite  or 
component,  analogue  or  digital  and  the  methods  of  performing  any  necessary 
conversion  to  and  from  the  source  coding  format  are  not  subject  to 
recommendation-.. 

2.2  Digital  output  and  input 

The  video  coder  provides  a  self-contained  digital  bit  scream  which 
be  combined  with  ocher  multi -facility  signals  (for  example  as  defined  in 
Recommendation  H.221).  The  video  decoder  performs  the  reverse  process. 

2.3  Sampling  frequency 

Pictures  are  sampled  at  an  integer  multiple  of  the  video  line  rate. 

This  sampling  clock  and  the  digital  network  clock  are  asynchronous. 
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2.4  Source  coding  algorithm 

A  hybrid  of  inter-picture  prediction  to  utilize  temporal  redundancy  and 
transform  coding  of  the  remaining  signal  to  reduce  spatial  redundancy  is 
adopted.  The  decoder  has  motion  compensation  capability,  allowing  optional 
incorporation  of  this  technique  in  the  coder. 

2.5  Bit  rate 

This  Recommendation  is  primarily  intended  for  use  at  video  bit  rates 
between  approximately  40  kbit/s  and  2  Mbit/s. 

2.6  Symmetry  of  transmission 

The  codec  may  be  used  for  bidirectional  or  unidirectional  visual 
communication. 

2.7  Error  handling 

The  transmitted  bit-stream  contains  a  BCH  (511,493)  Forward  Error 
Correction  Code.  Use  of  this  by  the  decoder  is  optional. 

2.8  Multipoint  operation 

Features  necessary  to  support  switched  multipoint  operation  are 

included. 


3 .  Source  coder 

3.1  Source  format 

The  source  coder  operates  on  non-interlaced  pictures  occurring 
30000/1001  (approximately  29.97)  times  per  second.  The  tolerance  on  picture 
frequency  is  ±50  ppm. 

Pictures  are  coded  as  luminance  and  two  colour  difference  components 
(Y,  Cg  and  Cg) .  These  components  and  the  codes  representing  their  sampled  values 
are  as  defined  in  CCIR  Recommendation  601. 

Black  •  16 

White  -  235 

Zero  colour  difference  -  128 

Peak  colour  difference  -  16  and  240 

These  values  are  nominal  ones  and  the  coding  algorithm  functions  with 
input  values  of  1  through  to  254. 

Two  picture  scanning  formats  are  specified. 

In  the  first  format  (GIF) ,  the  luminance  sampling  structure  is 
352  pels  per  line,  288  lines  per  picture  in  an  orthogonal  arrangement.  Sampling 
of  each  of  the  two  colour  difference  components  is  at  144  lines,  176  pels  per 
line,  orthogonal.  Colour  difference  samples  are  sited  such  that  their  clock 
boundaries  coincide  with  luminance  block  boundaries  as  shown  in  Figure  2/H.261. 
The  picture  area  covered  by  these  numbers  of  pels  and  lines  has  an  aspect  ratio 
of  4:3  and  corresponds  to  the  active  portion  of  the  local  standard  video  input. 
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Note  •  The  nunber  of  pels  per  line  is  compatible  with  sampling  the  active 
portions  of  the  luminance  and  colour  difference  signals  from  525-  or  625 -line 
sources  at  6.75  and  3.375  MHz  respectively.  These  frequencies  have  a  simple 
relationship  to  those  in  CCIR  Recommendation  -lOl. 


X  X 

o 

X  X 


X  X 

o 

X  X 


X  X 

o 

X  X 


X  LOKIMAMCt  SAMFLC 
o  aOOKIKAJICC  SA>9LI 
-  BLOCZ  EOCC 


FIGURE  2/H.261 

Positioning  of  luminance  and  chrominance  samples 

The  second  format,  Quarter-CIF  (QCIF),  has  half  the  number  of  pels  and 
half  the  number  of  lines  stated  above.  All  codecs  must  be  able  to  operate  using 
QCIF.  Some  codecs  can  also  operate  with  CIF. 

Means  shall  be  provided  to  restrict  the  maximum  picture  rate  of 
encoders  by  having  at  least  0,  1,  2  or  3  non- transmitted  pictures  between 
transmitted  ones.  Selection  of  this  minimum  number  and  CIF  or  QCIF  shall  be  by 
external  means  (for  example  via  Recommendation  H.221}. 

3.2  Video  source  coding  algorithm 

The  source  coder  is  shown  in  generalized  form  in  Figure  3/H.261.  The 
main  elements  are  prediction,  block  transformation  and  quantization. 

The  prediction  error  (INTER  mode)  or  the  input  picture  (INTRA  mode)  is 
subdivided  into  8  pel  by  8  line  blocks  which  are  segmented  as  transmitted  or 
non- transmitted.  Further,  four  luminance  blocks  and  the  two  spatially 
corresponding  colour  difference  blocks  are  combined  to  form  a  macroblock  as 
shown  in  Figure  10/H.26I  of  §  4.2.4. 

The  criteria  for  choice  of  mode  and  transmitting  a  block  are  not 
subject  to  recommendation  and  may  be  varied  dynamically  as  part  of  the  coding 
control  strategy.  Transmitted  blocks  are  transformed  and  resulting  coefficients 
are  quantized  and  variable  -length  coded. 

3.2.1  Prediction 

The  prediction  is  inter-picture  and  may  be  augmented  by  motion 
compensation  (§  3.2.2)  and  a  spatial  filter  (§  3.2.3). 
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T1502441-90 


To  Video 

Multiplex 

Coder 


T;  Transfona 
Q:  Quantizer 

P:  Picture  Memory  with  motion  compensated  variable  delay 
F:  Loop  filter 
CC:  Coding  control 

p:  Flag  for  INTRA/INTER 
t:  Flag  for  transmitted  or  not 
qz:  Quantizer  indication 

q:  Quantizing  index  for  transform  coefficients 
v:  Motion  vector 

f:  Switching  on/off  of  the  loop  filter 

FIGURE  3/H.261 


Source  coder 


3.2.2  Motion  compensation 

Motion  compensation  (HC)  is  optional  in  the  encoder.  The  decoder  will 
accept  one  vector  per  macroblock.  Both  horizontal  and  vertical  components  of 
these  motion  vectors  have  integer  values  not  exceeding  ±15.  The  vector  is  used 
for  all  four  luminance  blocks  in  the  macroblock.  The  motion  vector  for  both 
colour  difference  blocks  is  derived  by  halving  the  component  values  of  the 
macroblock  vector  and  truncating  the  magnitude  parts  towards  zero  to  yield 
integer  components . 


A  positive  value  of  Che  horizontal  or  vertical  component  of  the  motion 
vector  signifies  chat  the  prediction  is  formed  from  pels  in  the  previous  picture 
which  are  spatially  to  the  right  or  below  the  pels  being  predicted. 
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Hocion  vectors  are  restricted  such  chat  all  pels  referenced  by  them  are 
within  Che  coded  picture  area. 

3.2.3  LgQP_£ilgsr 

The  prediction  process  may  be  modified  by  a  two-dimensional  spatial 
filter  (FIL)  which  operates  on  pels  within  a  predicted  8  by  8  block. 

The  filter  is  separable  into  one -dimensional  horizontal  and  vertical 
functions.  Both  are  non- recursive  with  coefficients  of  1/4,  1/2,  1/4  except  at 
block  edges  where  one  of  the  taps  would  fall  outside  the  block.  In  such  cases 
Che  1-D  filter  is  changed  to  have  coefficients  of  0,  1,  0.  Full  arithmetic 
precision  is  retained  with  rounding  to  8  bit  integer  values  at  the  2-D  filter 
output.  Values'  whose* fractional  part  is  one  half  are  rounded  up: 

The  filter  is  switched  on/off  for  all  six  blocks  in  a  macroblock 
according  to  Che  macroblock  type  (see  §  4.2.3  MTYFE) . 

3.2.4  Transformer 

Transmitted  blocks  are  first  processed  by  a  separable  two-dimensional 
Discrete  Cosine  Transform  of  size  8  by  8.  The  output  from  Che  inverse  transform 
ranges  from  -256  to  +255  after  clipping  to  be  represented  with  9  bits.  The 
transfer  function  of  the  inverse  transform  is  given  by; 

7  7 

f(x.y)  -1/41  S  C(u)  C(v)  F(u,v)  cos(P(2x  +  l)u/16]  cos(P(2y  +  l)v/16] 
u—0  vM) 

with  u,  V,  X,  y-0,  1,  2,  ....7 

where  x,y  -  spatial  coordinates  in  the  pel  domain 

u,v  —  coordinates  in  the  transform  domain 

C(u)  -  1/75  for  u  -  0,  otherwise  1 
C(v)  -  \/Jl  for  V  -  0,  otherwise  1 

Note  -  Within  Che  block  being  transformed,  x  -  0  and  y-0  refer  to  the  pel 
nearest  Che  left  and  top  edges  of  Che  picture  respectively. 

The  arithmetic  procedures  for  computing  the  transforms  are  not  defined, 
but  Che  inverse  one  should  meet  the  error  tolerance  specified  in  Annex  1. 

3.2.5  Quantization 

The  number  of  quantizers  is  1  for  the  INTRA  dc  coefficient  and  31  for 
all  ocher  coefficients.  Within  a  macroblock  the  same  quantizer  is  used  for  all 
coefficients  except  Che  INTRA  dc  one.  The  decision  levels  are  not  defined.  The 
INTRA  dc  coefficient  is  nominally  the  transform  value  linearly  quantized  with  a 
stepsize  of  8  and  no  dead- zone.  Each  of  Che  other  31  quantizers  is  also 
nominally  linear  but  with  a  central  dead-zone  around  zero  and  with  a  step  size 
of  an  even  value  in  the  range  2  to  62. 

The  reconstruction  levels  are  as  defined  in  §  4.2.4. 

Note  -  For  the  smaller  quantization  step  sizes,  the  full  dynamic  range  of  the 
transform  coefficients  cannot  be  represented. 
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3.2.6  Clipping  of  reconstructed  picture 

To  prevent  quantization  distortion  of  transform  coefficient  amplitudes 
causing  arithmetic  overflow  in  the  encoder  and  decoder  loops,  clipping  functions 
are  inserted.  The  clipping  function  is  applied  to  the  reconstructed  picture 
which  is  formed  by  summing  the  prediction  and  the  prediction  error  as  modified 
by  the  coding  process.  This  clipper  operates  on  resulting  pel  values  less  than  0 
or  greater  than  255,  changing  them  to  0  and  255  respectively. 

3.3  Coding  control 

Several  parameters  may  be  varied  to  control  the  rate  of  generation  of 
coded  video  data.  These  include  processing  prior  to  the  source  coder,  the 
quantizer,  block  significance  criterion  and  temporal  subsampling.  The 
proportions  of  such  measures  in  the  overall  control  strategy  are  not  subject  to 
recommendation. 

When  Invoked,  temporal  subsampling  is  performed  by  discarding  complete 

pictures . 

3.4  Forced  updating 

This  function  is  achieved  by  forcing  the  use  of  the  INTRA  mode  of  the 
coding  algorithm.  The  update  pattern  is  not  defined.  For  control  of  accumulation 
of  inverse  transform  mismatch  error  a  macroblock  should  be  forcibly  updated  at 
least  once  per  every  132  times  it  is  transmitted. 

4.  VUgq, 

4.1  Data  structure 

Unless  specified  otherwise  the  most  significant  bit  is  transmitted 
first.  This  is  bit  1  and  is  the  leftmost  bit  in  the  code  tables  in  this 
document.  Unless  specified  otherwise  all  unused  or  spare  bits  are  set  to  "1". 
Spare  bits  must  not  be  used  until  their  f\inctions  are  specified  by  the  CCITT. 

4.2  Video  multiplex  arrangement 

The  video  multiplex  is  arranged  in  a  hierarchical  structure  with  four 
layers.  From  top  to  bottom  the  layers  are; 

Picture 

Group  of  blocks  (GOB) 

Hacroblock  (MB) 

Block 

A  syntax  diagram  of  the  video  multiplex  coder  is  shown  in 
Figure  4/H.261.  Abbreviations  are  defined  in  later  sections. 

4.2.1  Picture  layer 

Data  for  each  picture  consists  of  a  picture  header  followed  by  data  for 
GOBs.  The  structure  is  shown  in  Figure  5/H.261.  Picture  headers  for  dropped 
pictures  are  not  transmitted. 
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PICTURE  LAYER 


GOB  LAYER 


MB  LAYER 


BLOCK  LAYER 


Fixed  length 


O  Variable  length 


FIGURE  4/H.261 

Syntax  diaeratn  Cor  the  video  multiplex  coder 
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i 


I  L^SC  :  TR  :  PTYPE  :  PEI  :  PSPASRE  :  PEI  :  GOB  Data  | 


FIGURE  5/H.261 

Structure  of  picture  layer 

Picture  Start  Code  (PSC)  20  bits 

A  word  of  20  bits.  Its  value  is  0000  0000  0000  0001  0000. 

Temporal  Reference  (TR)  5  bits 

A  5-bic  number  which  can  have  32  possible  values.  It  is  formed  by 
incrementing  its  value  in  the  previously  transmitted  pictxire  header  by  one  plus 
the  number  of  non- transmitted  pictures  (at  29.97  Hz)  since  chat  last  transmitted 
one.  The  arithmetic  is  performed  with  only  Che  five  LSBs. 

Type  Information  (PTYPE)  6  bits 


Information  about  Che  complete  picture: 


- 

Bit 

1: 

Split  screen  indicator.  "0” 

off,  "1"  on. 

- 

Bit 

2: 

Document  camera  indicator. 

"0"  off,  "1" 

- 

Bit 

3: 

Freeze  Picture  Release.  "0" 

off,  "1"  on. 

- 

Bit 

4: 

Source  Format.  "0"  QCIF,  "1 

"  CIF. 

- 

Bits 

5 

to  6 :  Spare . 

Extra  Insertion  Information  (PEI)  1  bit 

A  bit  which  when  set  to  "1"  signals  Che  presence  of  Che  following 
optional  data  field. 

Spare  Information  (PSPARE)  0/8/16  . . .  bits 

If  PEI  is  set  Co  "1" ,  Chen  9  bits  follow  consisting  of  8  bits  of  data 
(PSPARE)  and  then  another  PEI  bit  to  indicate  if  a  further  9  bits  follow  and  so 
on.  Encoders  must  not  insert  PSPARE  until  specified  by  the  CCITT.  Decoders  must 
be  designed  to  discard  PSPARE  if  PEI  is  sec  to  1.  This  will  allow  the  CCITT  to 
specify  future  "backward"  compatible  additions  in  PSPARE. 

4.2.2  Group  of  blocks  layer 

Each  picture  is  divided  into  groups  of  blocks  (GOBs) .  A  group  of  blocks 
(GOB)  comprises  one  twelfth  of  the  GIF  or  one  third  of  the  QCIF  picture  areas 
(see  Figure  6/H,261).  A  GOB  relates  to  176  pels  by  48  lines  of  Y  and  the 
spatially  corresponding  88  pels  by  24  lines  of  each  of  Cg  and  C^^. 

Data  for  each  group  of  blocks  consists  of  a  GOB  header  followed  by  data 
for  macroblocks.  The  structure  is  shown  in  Figure  7/H.261.  Each  GOB  header  is 
transmitted  once  between  Picture  Start  Codes  in  the  CIF  or  QCIF  sequence 
numbered  in  Figure  6/H.261,  even  if  no  macroblock  data  is  present  in  that  GOB. 

Group  of  blocks  Start  Code  (GBSC)  16  bits 

A  word  of  16  bits,  0000  0000  0000  0001. 
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FIGURE  6/H.261 


Arrangement  of  GOBs  in  a  picture 


I  GBSC  :  GM  :  GQUANT  :  GEI  :  GSPARE  :  GEI  ;  MB  Data  | 


FIGURE  7/H.261 

Structure  of  group  of  blocks  layer 

Group  Number  (GN)  4  bits 

Four  bits  Indicating  the  position  of  the  group  of  blocks.  The  bits  are 
the  binary  representation  of  the  number  in  Figure  6/H.261.  Group  numbers  13,  14 
and  15  are  reserved  for  future  use.  Group  number  0  is  used  in  the  FSC. 

Quantizer  Information  (GQUANT)  5  bits 

A  fixed  length  codeword  of  5  bits  which  indicates  the  quantizer  to  be 
used  in  the  group  of  blocks  until  overridden  by  any  subsequent  MQUANT.  The 
codewords  are  the  natural  binary  representations  of  the  values  of  QUANT 
(§  4.2.4)  which,  being  half  the  step  sizes,  range  from  1  to  31. 

Extra  Insertion  Information  (GEI)  1  bit 

A  bit  which  when  set  to  "1"  signals  the  presence  of  the  following 
optional  data  field. 

Spare  Information  (GSPARE)  0/8/16  . . .  bits 

If  GEI  is  set  to  "1",  then  9  bits  follow  consisting  of  8  bits  of  data 
(GSPARE)  and  then  another  GEI  bit  to  indicate  if  a  further  9  bits  follow  and  so 
on.  Encoders  must  not  insect  GSPARE  until  specified  by  the  CCITT.  Decoders  must 
be  designed  to  discard  GSPARE  if  GEI  is  set  to  1.  This  will  allow  the  CCITT  to 
specify  future  "backward”  compatible  additions  in  GSPARE. 

Note  -  Emulation  of  start  codes  may  occur  if  the  future  specification  of  GSPARE 
has  no  restrictions  on  the  final  GSPARE  data  bits. 
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^■2.3  Macroblock  layer 

Each  GOB  is  divided  into  33  macroblocks  as  shown  in  Figure  8/H.261.  A 
macroblock  relates  to  16  pels  by  16  lines  of  Y  and  the  spatially  corresponding 
8  pels  by  8  lines  of  each  of  Cg  and  Cj^. 


1|  2|  3|  4|  51  6|  7|  8|  9|10|11 

12  1  13  I  14  I  15  I  16  I  17  I  18  I  19  I  20  I  21  I  22 

23  I  24  I  25  1  26  I  27  I  28  I  29  I  30  1  31  I  32  I  33 


FIGURE  8/H.261 

Arrangement  of  macroblocks  in  a  GOB 

Data  for  a  macroblock  consists  of  a  MB  Header  followed  by  data  for 
blocks  (Figure  9/H.261).  MQUANT,  MVD  and  GBP  are  present  when  indicated  by 
MTYPE. 


I  MBA  :  MTYPE  ;  MQUANT  :  MVD  :  CBP  :  Block  Data  | 


FIGURE  9/H.261 

Structure  of  macroblock  layer 
Macroblock  Address  (MBA)  Variable  Length 

A  variable  length  codeword  indicating  the  position  of  a  macroblock 
within  a  group  of  blocks.  The  transmission  order  is  as  shown  in  Figure  8/H.261 
For  the  first  transmitted  macroblock  in  a  GOB,  MBA  is  the  absolute  address  in 
Figure  8/H.261.  For  subsequent  macroblocks,  MBA  is  the  difference  between  the 
absolute  addresses  of  the  macroblock  and  the  last  transmitted  macroblock.  The 
code  table  for  MBA  is  given  in  Table  l/H.261. 

An  extra  codeword  is  available  in  the  table  for  bit  stuffing 
immediately  after  a  GOB  header  or  a  coded  macroblock  (MBA  Stuffing) .  This 
codeword  should  be  discarded  by  decoders . 

The  VLC  for  start  code  is  also  shown  in  Table  l/H.261. 
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TABLE  1/H.261 

VLC  table  for  macroblock  addressing 


MBA 

CODE 

MBA 

CODE 

1 

1 

17 

0000  0101  10 

2 

Oil 

18 

0000  0101  01 

3 

010 

19 

0000  0101  00 

4 

0011 

20 

0000  0100  11 

5 

0010 

21 

0000  0100  10 

6 

0001  1 

22 

0000  0100  oil 

7 

0001  0 

23 

0000  0100  010 

8 

0000  111 

24 

0000  0100  001 

9 

0000  110 

25 

0000  0100  000 

10 

0000  1011 

26 

0000  0011  111 

11 

0000  1010 

27 

0000  0011  110 

12 

0000  1001 

28 

0000  0011  101 

13 

0000  1000 

29 

0000  0011  100 

14 

0000  0111 

30 

0000  0011  oil 

15 

0000  0110 

31 

0000  0011  010 

16 

0000  0101  11 

32 

0000  0011  001 

33 

0000  0011  000 

MBA  Scuffing 

0000  0001  111 

Start  code 

0000  0000  0000  0001 

MBA  Is  always  included  in  transmitted  macroblocks. 

Macroblocks  are  not  transmitted  when  the  contain  no  information  for 
that  part  of  the  picture. 

Type  Information  (MTYFE)  Variable  Length 

Variable  length  codewords  giving  information  about  the  macroblock  and 
which  data  elements  are  present.  Macroblock  types,  included  elements  and  VLC 
words  are  listed  in  Table  2/H.261. 

MTYFE  is  always  included  in  transmitted  macroblocks. 
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TABLE  2/H.261 
VLC  table  for  MTYPE 


Prediction 

MQUANT 

MVD 

CBP 

TCOEFF 

VLC 

Intra 

X 

0001 

Intra 

X 

X 

0000 

001 

Inter 

X 

X 

1 

Inter 

X 

X 

X 

0000 

1 

Inter  +  MC 

X 

0000 

0000 

1 

Inter  +  MC 

X 

X 

X 

0000 

0001 

Inter  +  MC 

X 

X 

X 

X 

0000 

0000 

01 

Inter  +  MC 

+ 

FIL 

X 

001 

Inter  +  MC 

+ 

FIL 

X 

X 

X 

01 

Inter  +  MC 

+ 

FIL 

X 

X 

X 

X 

0000 

01 

Note  1  -  "x”  means  Chat  the  item  Is  present  In  the  macroblock. 

Note  2  -  It  Is  possible  to  apply  the  filter  In  a  non*motlon  compensated 
macroblock  by  declaring  It  as  MC  -t-  FIL  but  with  a  zero  vector. 

Quantizer  (MQUANT)  5  bits 

MQUANT  is  present  only  if  so  indicated  by  MTYPE. 

A  codeword  of  3  bits  signifying  the  quantizer  to  be  used  for  this  and 
any  following  blocks  in  the  group  of  blocks  until  overridden  by  any  subsequent 
MQUANT. 


Codewords  for  MQUANT  are  the  same  as  for  GQUANT. 

Motion  Vector  Data  (MVD)  Variable  length 

Motion  Vector  Data  is  included  for  all  MC  macroblocks.  MVD  is  obtained 
from  the  macroblock  vector  by  subtracting  the  vector  of  the  preceding 
macroblock.  For  this  calculation  the  vector  of  the  preceding  macroblock  is 
regarded  as  zero  in  the  following  three  situations: 

1)  Evaluating  MVD  for  macroblocks  1,  12  and  23. 

2)  Evaluating  MVD  for  macroblocks  in  which  MBA  does  not  represent  a 
difference  of  1. 

3)  MTYPE  of  the  previous  macroblock  was  not  MC. 

MVD  consists  of  a  variable  length  codeword  for  the  horizontal  component 
followed  by  a  variable  length  codeword  for  the  vertical  component.  Variable 
length  codes  are  given  in  Table  3/H.261. 

Advantage  is  taken  of  the  fact  that  the  range  of  motion  vector  values 
is  constrained.  Each  VLC  word  represents  a  pair  of  difference  values.  Only  one 
of  the  pair  will  yield  a  macroblock  vector  falling  within  the  permitted  range. 
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Coded  Block  Pattern  (CBP)  Variable  length 

CEP  la  present  if  indicated  by  MTYPE.  The  codeword  gives  a  pattern 
number  signifying  those  blocks  in  the  macroblock  for  which  at  least  one 
transform  coefficient  is  transmitted.  The  pattern  number  is  given  by: 

32*Pi  +  16*P2  +  8*P3  +  4*P4  +  2*?^  +  Pg 

where  P^^  is  1  if  any  coefficient  is  present  for  block  n,  else  0.  Block  numbering 
is  given  in  Figure  10/H.261. 

The  codewords  for  CBP  are  given  in  Table  4/H.261. 


TABLE  3/H.261  TABLE  4/H.261 

VLC  table  for  MVP  VLC  tflblg  far 


MVD 

CODE 

CBP 

CODE 

CBP 

CODE 

-16 

& 

16 

0000 

0011 

001 

60 

111 

35 

0001 

1100 

-15 

& 

17 

0000 

0011 

oil 

4 

1101 

13 

0001 

1011 

-14 

& 

18 

0000 

0011 

101 

8 

1100 

49 

0001 

1010 

-13 

& 

19 

0000 

0011 

111 

16 

1011 

21 

0001 

1001 

-12 

& 

20 

0000 

0100 

001 

32 

1010 

41 

0001 

1000 

-11 

& 

21 

0000 

0100 

oil 

12 

1001 

1 

14 

0001 

0111 

-10 

& 

22 

0000 

0100 

11 

48 

1001 

0 

50 

0001 

0110 

-9 

& 

23 

0000 

0101 

01 

20 

1000 

1 

22 

0001 

0101 

-8 

& 

24 

0000 

0101 

11 

40 

1000 

0 

42 

0001 

0100 

-7 

& 

25 

0000 

0111 

28 

0111 

1 

15 

0001 

0011 

-6 

& 

26 

0000 

1001 

44 

0111 

0 

51 

0001 

0010 

-5 

& 

27 

0000 

1011 

52 

0110 

1 

23 

0001 

0001 

-4 

& 

28 

0000 

111 

56 

0110 

0 

43 

0001 

0000 

-3 

& 

29 

0001 

1 

1 

0101 

1 

25 

0000 

1111 

-2 

& 

30 

0011 

61 

0101 

0 

37 

0000 

1110 

-1 

oil 

2 

0100 

1 

26 

0000 

1101 

0 

1 

62 

0100 

0 

38 

0000 

1100 

1 

010 

24 

0011 

11 

29 

0000 

1011 

2 

& 

-30 

0010 

36 

0011 

10 

45 

0000 

1010 

3 

a 

-29 

0001 

0 

3 

0011 

01 

53 

0000 

1001 

4 

a 

-28 

0000 

110 

63 

0011 

00 

57 

0000 

1000 

5 

a 

-27 

0000 

1010 

5 

0010 

111 

30 

0000 

0111 

6 

a 

-26 

0000 

1000 

9 

0010 

110 

46 

0000 

0110 

7 

a 

-25 

0000 

0110 

17 

0010 

101 

54 

0000 

0101 

8 

a 

-24 

0000 

0101 

10 

33 

0010 

100 

58 

0000 

0100 

9 

a 

-23 

0000 

0101 

00 

6 

0010 

oil 

31 

0000 

0011  1 

10 

a 

-22 

0000 

0100 

10 

10 

0010 

010 

47 

0000 

0011  0 

11 

a 

-21 

0000 

0100 

010 

18 

0010 

001 

55 

0000 

0010  1 

12 

a 

-20 

0000 

0100 

000 

34 

0010 

000 

59 

0000 

0010  0 

13 

a 

-19 

0000 

0011 

110 

7 

0001 

1111 

27 

0000 

0001  1 

14 

a 

-18 

0000 

0011 

100 

11 

0001 

1110 

39 

0000 

0001  0 

15 

a 

-17 

0000 

0011 

010 

19 

0001 

1101 
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4.2.4  Block  layer 

A  macroblock  comprises  four  luminance  blocks  and  one  of  each  of  the  two 
colour  difference  blocks  (Figure  10/H.261). 


I  1  I  2  I  I  I  I  I 

I . I  I  5  I  I  6  I 

I  3  I  4  I  I  I  I  I 

Y  Cb  Cr 

FIGURE  10/H.261 

Arrangement  of  blocks  In  a  macroblock 

Data  for  a  block  consists  of  codewords  for  transform  coefficients 
followed  by  an  end  of  block  marker  (Figure  11/H.261).  The  order  of  block 
transmission  Is  as  In  Figure  10/H.261. 


I  TCOEFF  I  EOB  | 


FIGURE  11/H.261 
Structure  of  block  layer 
Transform  Coefficients  (TCOEFF) 

Transform  coefficient  data  Is  always  present  for  all  six  blocks  In  a 
macroblock  when  MTYFE  Indicates  INTRA.  In  other  cases  MTYFE  and  CBP  signal  which 
blocks  have  coefficient  data  transmitted  for  them.  The  quantized  transform 
coefficients  are  sequentially  transmitted  according  to  the  sequence  given  In 
Figure  12/H.261. 


15 


16 


28 


29 


3 

4 


5 

9 


8 

13 


14 

18 


17 

26 


27 

31 


30 

42 


43 

44 


10 

11 


12 

20 


19 

24 


25 

33 


32 

40 


41 

46 


45 

53 


54 

55 


21 

22 

36 


23 

35 

37 


34 

38 

49 


39 

48 

50 


47 

51 

58 


52 

57 

59 


56 

60 

63 


61 

62 

64 


>  increasing  cycles  per 
plcttire  width 


V 

Increasing  cycles  per 
picture  height 


FIGURE  12/H.261 

Transmission  order  for  transform  coefficients 
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The  most  commonly  occurring  combinations  of  successive  zeros  (RUN)  and 
the  following  value  (LEVEL)  are  encoded  with  variable  length  codes .  Other 
combinations  of  (RUN,  LEVEL)  are  encoded  with  a  20-blt  word  consisting  of  6  bits 
ESCAPE,  6  bits  RUN  and  8  bits  LEVEL.  For  the  variable  length  encoding  there  are 
two  code  tables,  one  being  used  for  the  first  transmitted  LEVEL  In  INTER, 
INTER+MC  and  INTER+MC+FIL  blocks,  the  second  for  all  other  LEVELS  except  the 
first  one  In  INTRA  blocks  i^ich  Is  fixed  length  coded  with  8  bits. 

Codes  are  given  in  Table  S/H.261. 

TABLE  5/H.261 
VLC  table  for  TCOEFF 


The  most  commonly  occurring  combinations  of  zero-run  and  the  following 
value  are  encoded  with  variable  length  codes  as  listed  in  the  table  below.  End 
of  block  (EOB)  la  In  this  set.  Because  CBF  Indicates  those  blocks  with  no 
coefficient  data,  EOB  cannot  occur  as  the  first  coefficient.  Hence  EOB  can  be 
removed  from  the  VLC  table  for  the  first  coefficient. 


The  last  bit  "s"  denotes  the  sign  of  the  level. 


•0"  for  positive 
•I*  for  negative. 


RUN 


LEVEL 


CODE 


EOB 


10 

la  IF  FIRST  COEFFICIENT  IN  BLOCK 
(Note  -  Never  used  in  INTRA  macroblocks) 


0 

1 

11s 

NOT  FIRST 

COI 

0 

2 

0100 

s 

0 

3 

0010 

Is 

0 

4 

0000 

110s 

0 

5 

0010 

0110 

s 

0 

6 

0010 

0001 

s 

0 

7 

0000 

0010 

10s 

0 

8 

0000 

0001 

1101 

s 

0 

9 

0000 

0001 

1000 

s 

0 

10 

0000 

0001 

0011 

s 

0 

11 

0000 

0001 

0000 

s 

0 

12 

0000 

0000 

1101 

Os 

0 

13 

0000 

0000 

1100 

Is 

0 

14 

0000 

0000 

1100 

Os 

0 

15 

0000 

0000 

1011 

Is 

1 

1 

oils 

1 

2 

0001 

10s 

1 

3 

0010 

0101 

s 

1 

4 

0000 

0011 

00s 

1 

5 

0000 

0001 

1011 

s 

1 

6 

0000 

0000 

1011 

Os 

1 

7 

0000 

0000 

1010 

Is 

2 

1 

0101 

s 

2 

2 

0000 

100s 

2 

3 

0000 

0010 

11s 

2 

4 

0000 

0001 

0100 

s 

2 

5 

0000 

0000 

1010 

Os 
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3 

1 

0011  Is 

3 

2 

0010  0100 

s 

3 

3 

0000  0001 

1100 

s 

3 

4 

0000  0000 

1001 

Is 

4 

1 

0011  Os 

4 

2 

0000  0011 

11s 

4 

3 

0000  0001 

0010 

s 

5 

1 

0001  11s 

5 

2 

0000  0010 

01s 

5 

3 

0000  0000 

1001 

Os 

6 

1 

0001  01s 

6 

2 

0000  0001 

1110 

s 

7 

1 

0001  00s 

7 

2 

0000  0001 

0101 

s 

8 

1 

0000  Ills 

8 

2 

0000  0001 

0001 

s 

9 

1 

0000  101s 

9 

2 

0000  0000 

1000 

Is 

10 

1 

0010  0111 

s 

10 

2 

0000  0000 

1000 

Os 

11 

1 

0010  0011 

s 

12 

1 

0010  0010 

s 

13 

1 

0010  0000 

s 

14 

1 

0000  0011 

10s 

15 

1 

0000  0011 

01s 

16 

1 

0000  0010 

00s 

17 

1 

0000  0001 

1111 

s 

18 

1 

0000  0001 

1010 

s 

19 

1 

0000  0001 

1001 

s 

20 

1 

0000  0001 

0111 

s 

21 

1 

0000  0001 

0110 

s 

22 

1 

0000  0000 

1111 

Is 

23 

1 

0000  0000 

1111 

Os 

24 

1 

0000  0000 

1110 

Is 

25 

1 

0000  0000 

1110 

Os 

26 

1 

0000  0000 

1101 

Is 

ESCAPE 

0000  01 

The  remaining  combinations  of  (RON,  LEVEL)  are  encoded  with  a  20 -bit 
word^  consisting  of  6  bits  ESCAPE,  6  bits  RUN  and  8  bits  LEVEL. 


^  Use  of  this  20-bit  word  form  for  encoding  the  combinations  listed  in  the 
VLC  cable  is  not  prohibited. 
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RUN  is  a  6  bit  fixed  length  code.  LEVEL  is  an  8  bit  fixed  length  code. 


RUN 

CODE 

LEVEL 

CODE 

0 

0000  00 

-128 

FORBIDDEN 

1 

0000  01 

-127 

1000  0001 

2 

0000  10 

, 

• 

, 

-2 

1111  1110 

• 

-1 

1111  1111 

63 

1111  11 

0 

FORBIDDEN 

1 

0000  0001 

2 

0000  0010 

127 

0111  1111 

For  all  coefficients  other  than  the  INTRA  dc  one  the  reconstruction 
levels  (REC)  are  in  Che  range  -2048  to  2047  and  are  given  by  clipping  the 
results  of  the  following  formulae: 

REC  -  QUANT* (2*LEVEL+1)  ;  LEVEL>0  1 

\  QUANT  -  "odd" 

REC  -  QUANT* (2*LEVEL-1)  ;  LEVEL<0  J 

REC  -  QUANT*(2*LEVEL+1)-1:  LEVEL>0  1 

\  QUANT  -  "even" 

REC  -  QUANT*(2*LEVEL-1)+1:  LEVEL<0  J 
REC  -  0:  LEVELS 

Note  •  QUANT  ranges  from  1  to  31  and  is  transmitted  by  either  GQUANT  OR  HQUANT. 

TABLE  6/H.261 


Reconstruction  levels  (REC) 


LEVEL 

1 

2 

3 

4  . 

QUANT 

8  9  . 

17 

00 

30 

31 

-127 

-255 

-509 

-765 

-1019  . 

-2039 

-2048  . 

-2048 

-2048 

-2048 

-2048 

-126 

-253 

-505 

-759 

-1011  . 

-2023 

-2048  . 

-2048 

-2048  . 

-2048 

-2048 

-2 

-5 

-9 

-15 

-19  . 

-39 

-45  . 

-85 

-89 

-149 

-155 

-1 

-3 

-5 

-9 

-11  . 

-23 

-27  . 

-51 

-53  . 

-89 

-93 

0 

0 

0 

0 

0  . 

0 

0  . 

0 

0 

0 

0 

1 

3 

5 

9 

11  . 

23 

27  . 

51 

53 

89 

93 

2 

5 

9 

15 

19  . 

39 

45  . 

85 

89  . 

149 

155 

3 

7 

13 

21 

27  . 

55 

63  . 

119 

125  . 

209 

217 

4 

9 

17 

27 

35 

71 

81  . 

153 

161  . 

269 

279 

5 

11 

21 

33 

43 

87 

99  . 

187 

197 

329 

341 

56 

113 

225 

339 

451 

903 

1017 

1921 

2033 

2047 

2047 

57 

115 

229 

345 

459 

919 

1035  . 

1955 

2047 

2047 

2047 

58 

117 

233 

351 

467 

935 

1053 

1989 

2047 

2047 

2047 

59 

119 

237 

357 

475 

951 

1071 

2023 

2047  . 

2047 

2047 

60 

121 

241 

363 

483 

967 

1089 

2047 

2047 

2047 

2047 

125 

251 

501 

753 

1003 

2007 

2047 

2047 

2047 

2047 

2047 

126 

253 

505 

759 

1011 

2023 

2047 

2047 

2047 

2047 

2047 

127 

255 

509 

765 

1019 

2039 

2047 

2047 

2047 

2047 

2047 
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Note  -  Reconstruction  levels  are  symmetrical  with  respect  to  the  sign  of  LEVEL 
except  for  2047/-2048. 

For  INTRA  blocks  the  first  coefficient  is  nominally  the  transform  dc 
value  linearly  quantized  with  a  step  size  of  8  and  no  dead-zone.  The  resulting 
values  are  represented  with  8  bits.  A  nominally  black  block  will  give  0001  0000 
and  a  nominally  white  one  1110  1011.  The  code  0000  0000  is  not  used.  The  code 
1000  0000  is  not  used,  the  reconstruction  level  of  1024  being  coded  as  1111  1111 
(see  Table  7/H.261). 

Coefficients  after  the  last  non-zero  one  are  not  transmitted.  EOB  (end 
of  block  code)  is  always  the  last  item  in  blocks  for  which  coefficients  are 
transmitted . 


TABLE  7/H.261 

Reconstruction  levels  for  INTRA-mode  dc  coefficient 


FLC 

Reconstruction  level 
into  inverse  transform 

0000  0001 

(1) 

8 

0000  0010 

(2) 

16 

0000  0011 

(3) 

24 

0111  1111 

(127) 

1016 

1111  1111 

(255) 

1024 

1000  0001 

(129) 

1032 

1111  1101 

(253) 

2024 

1111  1110 

(254) 

2032 

Note  -  The  decoded  value  corresponding  to  FLC  "n"  is  8n  except  FLC  255 
gives  1024. 

4.3  Multipoint  considerations 

The  following  facilities  are  provided  to  support  switched  multipoint 
operation. 

4.3.1  Freeze  picture  request 

Causes  the  decoded  to  freeze  its  displayed  picture  until  a  freeze 
picture  release  signal  is  received  or  a  timeout  period  of  at  least  six  seconds 
has  expired.  The  transmission  of  this  signal  is  via  external  means  (for  example 
by  H.221) . 

4.3.2  Fast  update  request 

Causes  the  encoder  to  encode  its  next  picture  in  INTRA  mode  with  coding 
parameters  such  as  to  avoid  buffer  overflow.  The  transmission  method  for  this 
signal  is  via  external  means  (for  example  by  H.221). 
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^.3.3  Freeze  picture  release 

A  signal  from  an  encoder  which  has  responded  to  a  Fast  Update  Request 
and  allows  a  decoder  to  exit  from  its  freeze  picture  mode  and  display  decoded 
pictures  in  the  normal  manner.  This  signal  is  transmitted  by  bit  3  of  PTYPE 
(see  §  4.2.1)  in  the  picture  header  of  the  first  picture  coded  in  response  to 
Che  Fast  Update  Request. 

3.  Transmission  coder 

5.1  Bit  rate 

The  transmission  clock  is  provided  externally  (for  example  from  an 
1.420  interface). 

5.2  Video  data  buffering 

The  encoder  must  control  its  output  bitstream  to  comply  with  the 
requirements  of  the  Hypothetical  Reference  Decoder  defined  in  Annex  2. 

When  operating  with  GIF  the  number  of  bits  created  by  coding  any  single 
picture  must  not  exceed  256  kbit/s.  K  -  1024. 

When  operating  with  QCIF  Che  number  of  bits  created  by  coding  any 
single  picture  must  not  exceed  64  kbit/s. 

In  both  Che  above  cases  Che  bit  count  includes  the  Picture  Start  Code 
and  all  other  data  related  to  that  picture  including  PSPARE,  GSPARE  and  MBA 
Scuffing.  The  bit  count  does  not  include  error  correction  framing  bits,  fill 
indicator  (Fi) ,  fill  bits  or  error  correction  parity  information  described  in 
§  5.4  below. 

Video  data  must  be  provided  on  every  valid  clock  cycle.  This  can  oe 
ensured  by  the  use  of  either  the  fill  bit  indicator  (Fi)  and  subsequent  fill  all 
I's  bits  in  Che  error  corrector  block  framing  (see  Figure  13/H.261)  or  MBA 
Stuffing  (§  4.2.3)  or  both. 

5.3  Video  coding  delay 

This  item  is  included  in  this  Recommendation  because  Che  video  encoder 
and  video  decoder  delays  need  to  be  known  to  allow  audio  compensation  delays  to 
be  fixed  when  H.261  is  used  to  form  part  of  a  conversational  service.  This  will 
allow  lip  synchronization  to  be  maintained.  Annex  3  recommends  a  method  by  which 
the  delay  figures  are  established.  Other  delay  measurement  methods  may  be  used 
but  they  must  be  designed  in  a  way  to  produce  similar  results  to  the  method 
given  in  Annex  3. 

5.4  Forward  Error  Correction  for  coded  video  signal 
3.4.1  Error  correcting  code 

The  transmitted  bitstream  contains  a  BCH  (511,493)  Forward  Error 
Correction  Code.  Use  of  this  by  the  decoder  is  optional. 
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3.4.2  Generator  polynomial 

g(x)  -  (x^  +  x^  +  l)(x^  +  x^  +  x^  +  x3  +  1) 

Example:  for  the  input  data  of  "01111  ...  11"  (493  bits)  the  resulting 
correction  parity  bits  are  "011011010100011011"  (18  bits). 

5.4.3  Error  correction  framing 

To  allow  the  video  data  and  error  correction  parity  information  to  be 
identified  by  a  decoder  an  error  correction  framing  pattern  is  included.  This 
consists  of  a  multiframe  of  eight  frames,  each  frame  comprising  1  bit  framing, 

1  bit  fill  Indicator  (Fi) ,  492  bits  of  coded  data  (or  fill  all  Is)  and  18  bits 
parity.  The  frame  alignment  pattern  is: 

(3182333485568788)  -  (00011011). 

8ee  Figure  13/H.261  for  the  frame  arrangement.  The  parity  is  calculated 
against  the  493-bits  including  fill  indicator  (Fi). 

The  fill  indicator  (Fi)  can  be  set  to  zero  by  an  encoder.  In  this  case 
only  492  consecutive  fill  bits  (fill  all  Is)  plus  parity  are  sent  and  no  coded 
data  is  transmitted.  This  may  be  used  to  meet  the  requirement  in  §  5.2  to 
provide  video  data  on  every  valid  clock  cycle. 

Transmission  Order  — ♦  (S1S2S3S4S5S6S7S8)  =(00011011) 


Si 

1 

1 

Sg 

1  ^ 

TIS024«0-90 

Si 

Data 

Parity 

1 

493 

18 

- 

1 

COOED  DATA 

0 


FILL(all"l") 


1  492 


FIGURE  13/H.261 
Error  correcting  frame 

5.4.4  Relock  time  for  error  corrector  framing 

Three  consecutive  error  correction  framing  sequences  (24  bits)  should 
be  received  before  frame  lock  is  deemed  to  have  been  achieved.  The  decoder 
should  be  designed  such  that  frame  lock  will  be  re-established  within  34000  bits 
after  an  error  corrector  framing  phase  change . 

Note  -  This  assumes  that  the  video  data  does  not  contain  three  correctly  phased 
emulations  of  the  error  correction  framing  sequence  during  the  relocking 
period. 
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ANNEX  1 

(to  Reconunendation  H.261) 

Inverse  transform  accuracy  specification 


1.  Generate  random  Integer  pel  data  values  in  the  range  -L  to  -fH  according 
Co  the  random  number  generator  given  below  ("C"  version) .  Arrange  into 

8  by  8  blocks.  Data  set  of  10,000  blocks  should  each  be  generated  for  (L  -  256, 

H  -  255),  (L  -  H  -  5)  and  (L  -  H  -  300). 

2.  For  each  8  by  8  block,  perform  a  separable,  orchonormal,  matrix 
multiply.  Forward  Discrete  Cosine  Transform  tising  at  least  64-biC  floating  point 
accuracy . 

7  7 

F(u,v)  -  1/4  C(u)  C(v)  2  2  f(x,y)  cos(Pi(2x  +  l)u/16]  cos[Pi(2y  +  l)v/16] 

x-0  y»0 

with  u,  V,  X,  y-0,  1,  2 . 7 

where  x,y  •  spatial  coordinates  in  the  pel  domain 

u,v  -  coordinates  in  the  transform  domain 

C(u)  -  1/72  for  u  -  0,  otherwise  1 
C(v)  -  1/72  for  V  -  0,  ocharvise  1 

3.  For  each  block,  rovmd  the  64  resulting  transformed  coefficients  to  the 
nearest  integer  values.  Then  clip  them  to  the  range  -2048  to  +2047.  This  is  the 
12*bic  input  data  to  Che  inverse  transform. 

4.  For  each  8  by  8  block  of  12 -bit  data  produced  by  step  3,  perform  a 
separable,  orthonormal,  matrix  multiply.  Inverse  Discrete  Transform  (IDCT) 
using  at  least  64-bit  floating  point  accuracy.  Round  the  resulting  pels  to  the 
nearest  integer  and  clip  to  the  range  -256  to  +255.  These  blocks  of  8  by  8  pels 
are  the  "reference”  IDCT  input  data. 

5.  For  each  8  by  8  block  produced  by  step  3,  apply  the  IDCT  xinder  test 
and  clip  Che  output  to  Che  range  -256  to  +255.  These  blocks  of  8  by  8  pels  are 
Che  "test”  IDCT  output  data. 

6.  For  each  of  the  64  IDCT  output  pels,  and  for  each  of  the  10,000  block 
data  secs  generated  above,  measure  the  peak,  mean  and  mean  sqxxare  error  between 
the  "reference"  and  the  "test"  data. 


7. 


For  any  pel. 
For  any  pel, 
Overall,  the 
For  any  pel, 
Overall,  the 


Che  peak  error  should  not  exceed  I  in  magnitude. 

Che  mean  square  error  should  not  exceed  0.06. 
mean  square  error  should  not  exceed  0.02. 
the  mean  error  should  not  exceed  0.015  in  magnitude, 
mean  error  should  not  exceed  0.0015  in  magnitude. 
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8.  All  zeros  in  muse  produce  all  zeros  out. 

9.  Re*run  the  measurements  using  exactly  the  same  data  values  of  step  1, 
but  change  the  sign  on  each  pel. 

"C"  Program  for  random  number  generation 

/*  L  and  H  must  be  long,  that  is  32  bits  */ 
long  rand(L,H) 
long  L,H; 

{ 

static  long  randx  -  1;  /*  long  is  32  bits  */ 

static  double  z  -  (double)0x7fffffff ; 

long  i. j ; 

double  x;  /*  double  is  64  bits  */ 

randx  -  (randx  *  1103515245)  +  12345; 
i  -  randx  &  0x7ffffffe;  /*  keep  30  bits  */ 

X  -  (  (double) i  )  /  z;  /*  range  0  to  0.99999...  */ 

X  *  -  (L+H+1) ;  /*  range  0  to  <  L+H+1  */ 

J  -  x;  /*  trvincate  to  integer  */ 

retum(  j  -  L  ) ;  /*  range  -L  to  H  */ 
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ANNEX  2 

(to  Reconmendatlon  H.261) 
Hypothetical  Reference  Decoder 


The  Hypothetical  Reference  Decoder  (HRD)  is  defined  as  follows: 

1.  The  HRD  and  the  encoder  have  the  same  clock  frequency  as  well  as  the 
same  CIF  rate,  and  are  operated  s3mchronously. 

2.  The  HRD  receiving  buffer  size  is  (B  +  256  kbit/s).  The  value  of  B  is 
defined  as  follows: 

B  -  ^Raax/29  .97  where  Raax  maximum  video  bit  rate  to  be  used  in 

the  connection. 

3.  The  HRD  buffer  is  initially  empty. 

4.  The  HRD  buffer  is  examined  at  CIF  intervals  (-33  ms).  If  at  least  one 

complete  coded  picture  is  in  the  buffer  then  all  the  data  for  the  earliest 
pictxire  is  instantaneously  removed  (e.g.  at  in  Figure  A.1/H.261). 

Imnediately  after  removing  the  above  data  the  buffer  occupancy  must  be  less 
than  B.  This  is  a  requirement  on  the  coder  output  bitstream  including  coded 
picture  data  and  MBA  stuffing  but  not  error  correction  framing  bits,  fill 
indicator  (Fi) ,  fill  bits  or  error  correction  parity  information  described 

in  §  5.4. 


To  meet  this  requirement  the  number  of  bits  for  the  (N-t-l)th  coded 
picture  must  satisfy: 


'%+i  >  Bn 


’^N+l 

R(t)dt  .  B 
tN 


where  B^j  is  buffer  occupancy  Just  after  the  time  tj}. 


t{f  is  the  time  the  Nth  coded  picture  is  removed  from  the  HRD  buffer. 


R(t)  is  the  video  bit  rate  at  the  time  t. 
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HRD  buffer 
occupancy 


(bit) 


FIGURE  A.1/H.261 
HRD  buffer  occupancy 

liSifift  -  Time  (tjj+i  -  t(j)  is  an  integer  number  of  GIF  picture  periods  (1/29.97, 
2/29.97.  3/29.97,  ...), 
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ANNEX  3 

(Co  RecommendaCion  H.261) 
Codec  delay  measuremenC  method 


The  video  encoder  and  video  decoder  delays  will  vary  depending  on 
implementation.  The  delay  will  also  depend  on  the  picture  format  (QCIF,  CIF)  and 
data  rate  in  use.  This  section  specifies  Che  method  by  «diich  Che  delay  figures 
are  established  for  a  particular  design.  To  allow  correct  audio  delay 
compensation  the  overall  video  delay  needs  to  be  established  from  a  user 
perception  point  of  view  under  typical  viewing  conditions. 

B 


T1S02480-90 


FIGURE  A.2/H.261 
ttcaauiinE-P9int8 

Point  A  is  the  video  input  to  the  video  coder.  Point  B  is  the  channel 
output  from  the  video  terminal  (i.e.  including  any  FEC,  channel  framing  etc.). 
Point  C  is  the  video  output  from  the  decoder. 

A  video  sequence  lasting  more  than  100  seconds  is  connected  to  the 
video  coder  input  (point  A)  in  Figure  A.2/H.261  above.  The  video  sequence  should 
have  the  following  characteristics: 

it  should  contain  a  typical  moving  scene  consistent  with  the 
Intended  purpose  of  the  video  codec; 

it  should  produce  a  minimum  coded  picture  rate  of  7.5  Hz  at  the 
bit  rate  in  use; 

it  should  contain  a  visible  identification  mark  at  intervals 
throughout  the  length  of  the  sequence.  The  visible  identification 
should  change  every  97  video  input  frames  and  be  located  within 
the  picture  area  represented  by  the  first  GOB  in  the  picture.  For 
example,  the  first  block  in  the  picture  could  change  from  black 
to  white  at  intervals  of  97  video  frame  periods .  The 
identification  mark  should  be  chosen  so  that  it  can  be  detected 
at  point  B  and  does  not  significantly  contribute  to  the  overall 
coding  performance . 
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The  codec  and  video  sequence  should  be  arranged  so  Chat  the  bitstream 
contains  less  than  lOX  stuffing  (MBA  stuffing  +  error  correction  fill  bits) . 

The  encoder  delay  is  obtained  by  measuring  the  time  from  when  the 
visible  identification  changes  at  point  A  to  the  time  that  the  change  is 
detected  at  point  B.  Similarly,  the  decoder  delay  is  obtained  by  taking 
measurements  at  points  B  and  C. 

Several  measurements  should  be  made  during  the  sequence  length  and  the 
average  period  obtained.  Several  tests  should  be  made  to  ensure  that  a 
consistent  average  figure  can  be  obtained  for  both  encoder  and  decoder  delay 
times . 


Average  results  should  be  obtained  for  each  combination  of  picture 
format  and  bit  rate  within  the  capability  of  the  particular  codec  design. 

Note  -  Due  to  pre-  and  post-temporal  processing  it  may  be  necessary  to  take  a 
mid-level  for  establishing  the  transition  of  the  identification  mark  at 
points  B  and  C. 
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5.  Recommandation  H.320 

NARROtf-BAMD  VISUAL  TELEPHONE  SYSTEMS  AND  TERMINAL  EQUIPMENT 
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6 .  Maintenance 

7.  Human  factor  aspects 
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1 .  Scope 

This  Recommendation  covers  the  technical  requirements  for  narrow-band 
visual  telephone  services  defined  in  H. 200/AV. 120 -Series  Recommendations,  where 
channel  races  do  not  exceed  1920  kbit/s. 

Note  -  It  is  anticipated  that  this  Recommendation  will  be  extended  to  a  number 
of  Recommendations  each  of  which  would  cover  a  single  videoconferencing  or 
videophone  service  (narrow-band,  broadband  ...).  However,  large  parts  of  these 
Recommendations  would  have  identical  wording,  while  in  the  points  of  divergence 
the  actual  choices  between  alternatives  have  not  yet  been  made;  for  the  time 
being,  therefore,  it  is  convenient  to  treat  all  the  text  in  a  single 
Recommendation . 

The  service  requirements  for  visual  telephone  services  are  presented  in 
Recommendation  H. 200/AV. 120-Series;  video  and  audio  coding  systems  and  other 
technical  set  aspects  common  to  audiovisual  services  are  covered  in  other 
Recommendations  in  the  H. 200/AV. 200 -Series. 

2.  Definitions 

BAS :  Bit-rate  Allocation  Signal.  Bit  position  within  the  frame 
structure  of  H.221  to  transmit,  e.g.  commands,  control  and  indication  signals, 
capabilities. 

C&I !  End-to-e.iu  ^  ignalling  between  terminals  consisting  of  "control" 
which  causes  a  state  chan'je  in  the  receiver  and  "indication"  which  provides  for 
information  as  to  the  functioning  of  the  system,  see  also  H.230. 

Data  Port:  Input/output  gate  for  the  user  data  transmitted  within 
Service  Channel  or  sub-channels  according  to  H.221. 

Llo  Synchronization:  Operation  to  provide  feeling  that  speaking  motion 
of  the  displayed  person  is  synchronized  with  the  voice  the  person  makes. 

In-band  Signalling:  Signalling  via  BAS  of  the  H.221  frame  structure. 

MCU  (Multipoint  Control  Unit') :  A  piece  of  equipment  located  in  a  node 
of  the  network  or  in  a  terminal  which  receives  several  channels  from  access 
ports  and,  according  to  certain  criterions,  processes  audiovisual  signals  and 
distributes  them  to  the  connected  channels. 

MMI :  Man-machine  Interface  between  user  and  terminal/system  which 
consists  of  a  physical  section  (electro-acoustic,  electro-optic  transducer, 
keys,  ...)  and  a  logical  section  dealing  with  functional  operation  states. 

Narrow- band:  Bit  rates  ranging  from  64  kbit/s  to  1920  kbit/s.  This 
channel  capacity  may  be  provided  as  a  single  B/H0/H11/H12  channel  or  multiple 
B/HO  channels  in  ISDN. 

Outband  Signalling:  Signalling  via  a  channel  not  being  part  of  the 
B/H0/H11/H12  channel  (due  to  I .400-Series) . 

Visual  Telephone  Services:  A  group  of  audiovisual  services  including 
videophone  defined  in  F.721  and  videoconferencing  to  be  defined  in 
H. 200/AV. 112. 
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A  generic  vlsiial  telephone  system  is  shown  in  Figure  1/H.320.  It 
consists  of  terminal  equipment,  network.  Multipoint  Control  Unit  (MCU)  and  other 
system  operation  entities. 

A  configuration  of  the  terminal  equipment  consisting  of  several 
functional  units  is  also  shown  in  Figure  ly^.320.  "Video  1/0  equipment"  includes 
cameras,  monitors  and  video  processing  units  to  provide  functions  such  as 
split-screen  scheme.  "Audio  1/0  equipment"  Includes  microphones,  loud-speakers 
and  audio  processing  units  to  provide  such  fxinctions  as  acoustic  echo 
cancellation.  "Telematic  equipment"  are  visual  aids  such  as  electronic 
blackboard,  still  picture  transceiver  to  enhance  basic  visual  telephone 
communication.  "System  control"  unit  carries  out  such  functions  as  network 
access  throu^  "End- to -network  signalling"  and  end-to-end  control  to  establish 
common  mode  of  operation  and  signalling  for  proper  operation  of  the  terminal 
through  "End-to-end  signalling".  "Video  codec"  carries  out  redundancy  reduction 
coding  and  decoding  for  video  signals,  while  "audio  codec"  does  the  same  thing 
for  audio  signals .  "Delay"  in  the  audio  path  compensates  video  codec  delay  to 
maintain  lip  synchronization.  "Mtuc/dmux"  unit  multiplexes  transmitting  video, 
audio,  data  and  control  signals  into  a  single  bit  stream  and  demultiplexes  a 
received  bit  stream  into  consisting  multimedia  signals.  "Network  interface" 
makes  necessary  adaptation  between  the  network  and  the  terminal  according  to  the 
user-network  interface  requirements  defined  in  the  I. 400-Series. 

3.2  Signals 

Visvtal  telephone  signals  are  classified  into  video,  audio,  data  and 
control  as  follows: 

audio  signals  are  continuous  traffic  and  require  real-time 
transmission; 

Note  -  In  order  to  reduce  the  average  bit  rate  of  audio  signals,  voice 
activation  can  be  introduced  (in  which  case  the  audio  signals  are  no 
longer  continuous) . 

video  signals  are  also  continuoxis  traffic,  the  bit  rate  allocated 
to  video  signals  should  be  as  high  as  possible,  in  order  to 
maximize  the  quality  within  the  available  channel  capacity; 

-  data  signals  include  still  pictures,  facsimile  and  documents,  or 
other  facilities,  this  signal  may  occur  only  occasionally  as 
required  and  may  temporarily  displace  all  or  part  of  the 
audiovisual  signal  content.  It  should  be  noted  that  data  signals 
are  associated  only  with  optional  enhancements  to  the  basic 
visual  telephone  system,  therefore,  the  opening  of  a  path  to 
carry  such  signals  is  preceded  by  negotiation  between  the 
terminals ; 

control  signals  are  some  system  control  signals  by  definition. 

The  path  for  the  terminal- to-network  control  signals  is  provided 
in  the  D-channel,  while  the  path  for  the  terminal -to- terminal 
control  signals  is  provided  in  BAS  or  Service  Channel  only  when 
necessary  by  the  mechanism  defined  in  H.221. 
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3.3  Bit  rate  options  and  infrastructure 

3.3.1  Communicatton  modes  of  visual  telaohone 

Communication  modes  of  visual  telephone  are  defined  in  Table  1 
according  to  their  channel  configuration  and  coding. 

3.3.2  Terminal  tvoes  of  visual  telephone 

Table  2  lists  terminal  types  of  visual  telephone.  The  terminal  type  is 
categorized  according  to  the  communication  modes  and  the  type  of  communication 
channels  with  which  the  terminal  can  communicate;  m  x  B  (Type  X  with 
parameter  a-f),  n  x  HO  (Type  Y  with  parameter  1-5,  note),  H11/H12  (Type  Z  with 
parameter  a-B)  or  their  combinations . 

Note  -  Type  Y  terminals  must  have  the  H0-6B  compatibility  mode  defined  in 
Recommendation  H.221  for  interworking  of  evolving  networks. 

Examples 

Type  Xb3  is  a  terminal  capable  of  operating  at  modes  &q,  b^,  \>2 
and  b3  through  B  or  2  x  B  channel. 

-  Type  Xb3Yl  is  a  terminal  capable  of  operating  at  modes  sq,  a^, 
b^,  b2,  b3  and  g  through  B,  2  x  B  or  HO  channel. 

Type  XfY4Z  a  is  a  terminal  capable  of  operating  at  modes  aQ  -  k 
through  (1-6)  x  B,  (1-4)  x  HO  or  Hll  channel. 

For  H  x  B  and  N  x  HO  categories,  the  terminal  should  be  able  to  operate 
at  all  the  values  of  m  and  n  not  higher  than  M  and  N  in  principle  (note) .  The 
type  of  remote  terminal  is  identified  through  the  transfer  rate  capability 
exchange  defined  in  H.242. 

Note  -  Until  H.200/AV.2S4  is  recommended,  exceptions  may  arise. 

3.3.3  Video  codec 

As  per  Recommendation  H.261. 

3.3.4  Audio  codec 

As  per  Recommendations  G.711,  G.722,  H. 200/AV. 254,  AV.253,  see 
Table  1/H.320. 

3.3.5  Frame  structure 

As  per  Recommendation  H.211. 

3.3.6  C&I 

Identified  subset  of  H.230  is  used,  see  §  4.4. 

3.3.7  Communication  procedure 

As  per  Recommendation  H.242. 


CCITT\COMXV\RAPP\R037E5  TXS 


-  112  - 
COM  XV-R  37 -E 


3.4  Call  control  arrangements 

To  establish  intercommunication  between  various  audiovisual  terminals , 
it  is  necessary  Co  carry  out  in-band  and  out-band  procedures  according  to 
Recommendation  H.242  and  other  relevant  CCITT  Recommendations. 

The  different  stages  of  Che  call  are  referred  according  to  a 
point-to-point  configuration  where  terminal  X  is  the  calling  terminal  and  Y  the 
called  terminal. 

3.4.1  Establishment  of  a  visual  telephone  call  -  Normal  procedure 

The  provision  of  the  communication  is  made  in  the  main  following 

steps : 

Phase  A:  Call  set-up,  out-band  signalling; 

Phase  Bl:  Mode  initialization  on  initial  channel; 

Phase  CA:  Call  set-up  of  additional  channel ( s) ,  if  relevant; 

Phase  CBl:  Initialization  on  additional  channel(s); 

Phase  B2  (or  CB2):  Establishment  of  common  parameters; 

Phase  C:  Visual  telephone  communication; 

-  Phase  0:  Termination  phase; 

Phase  E:  Call  release. 

Phase  A  -  Call  set -up 

After  user  initialization,  Che  terminal  X  performs  a  call  set-up 
procedure.  As  soon  as  Che  terminal  receives  an  indication  from  Che  network  that 
Che  connection  is  established,  a  bidirectional  channel  is  opened  from 
end-to-end,  and  it  overlays  H.221  framing  on  Che  channel. 

Following  Che  connection  establishment,  all  the  terminals  will  start  to 
work  in  the  following  modes  defined  in  H.221: 

Type  X:  Mode  OF  (A-law  or  ti-lav); 

Type  Y  and  Type  Z:  Mode  OF  (A-law  or  |i-law)  audio  only. 

In-band  procedure  is  activated. 

Phase  Bl  -  Mode  initialization 
Phase  Bl-1 

Using  the  procedures  provided  in  H.242,  framed  PCM  audio  is  transmitted 
in  both  directions,  after  frame  and  mulciframe  alignment  terminal  capabilities 
are  exchanged. 
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Phase  Bl-2  (terminal  procedure) 

Decermlnatlon  of  the  appropriate  mode  to  be  transmitted.  This  will 
normally  be  the  highest  common  mode  (see  Table  3/H.320  for  the  case  using  a  B  or 
2  X  B  channel) ,  but  a  lower  compatible  mode  could  be  chosen  instead. 

In  the  case  that  both  terminals  have  announced  the  capability  to  work 
on  additional  channel(s),  terminal  X  initiates  the  request  for  supplementary 
call  set-up.  Alternatively,  this  action  may  be  suspended  until  the  user  at  X  has 
given  the  go-ahead,  the  Y  user  may  also  control  the  additional  channel  requests. 
It  is  for  further  study. 

Note  -  If  the  user  at  either  terminal  does  not  wish  the  call  to  proceed  to  two 
or  more  channels,  even  though  his  terminal  has  this  capability,  he  must  set  the 
terminal  such  that  only  single -channel  capability  is  declared  in  Phase  Bl-1.  In 
that  case,  we  should  distinguish  the  active  capability,  wished  by  the  users, 
from  the  virtual  capability  of  the  terminal. 

Phase  Bl-3  (Mode  switching) 

Both  terminals  switch  to  the  mode  they  have  identified  in  Phase  Bl-2, 
using  the  procedure  of  H.242. 

Note  -  If  the  terminals  have  not  both  adopted  the  common  mode,  an  asymmetric 
communication  may  result. 

Phase  CA  -  Call  set-uo  of  the  additional  channeKs) 

Following  Phase  Bl-3  and  Phase  B2  if  relevant,  Che  communicaClon 
Phase  C  proceeds  on  that  channel.  If  additional  channels  have  been  requested 
these  are  again  Phase  A  (hence  the  nomenclature  "Phase  CA"),  exactly  as  in 
Phase  A  above,  and  additional  call  set-ups  are  performed  by  the  terminals.  On 
each  of  Che  established  channels  H.221  framing  Is  overlaid  (note). 

Note  -  During  Phase  CA  an  intermediate  audiovisual  mode  could  be  offered  on  the 
initial  channel  used  for  initialization,  until  full  completion  of  Initialization 
phase . 

Phase  CBl  -  Mode  Initialization  on  additional  channeKs) 

Using  the  procedure  provided  In  H.242,  frame  and  multlframe  alignments 
are  gained. 

Fhaag  CBl -12 

S3mchronlzaclon  of  the  channels  Is  achieved. 

Phase  CBl- 2  (Terminal  procedure) 

Determination  of  Che  appropriate  mode  to  be  transmitted.  This  will 
normally  be  the  highest  common  mode,  but  a  lower  compatible  mode  could  be  chosen 
instead. 
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Phase  CBl-3  (Mode  switching) 

Both  terminals  switch  tc  the  mode  they  have  identified  in  Phase  Bl-2 
using  the  procedure  of  H.242. 

Note  -  Here  again,  if  the  terminals  have  not  both  adopted  the  common  mode,  an 
asymmetric  communication  will  result. 

Phase  B2  Xor  CB2)  -  Establishment  of  common  parameters 

This  phase  establishes  common  operational  parameters  specific  to  visual 
telephone  (e.g.  encryption)  after  Phase  B1  process  is  finished.  Capabilities  or 
requirements  of  the  receiving  side  are  first  indicated  then  the  sending  side 
decides  operational  parameters  and  controls  the  receiving ' side .  BAS  codes  for" 
this  purpose  are  defined  in  H.221. 

Phase  C  -  Visual  telephone  communication 

In  the  case  where  more  than  one  channel  is  used,  there  will  be 
Intermediate  Phases  CA,  CBl,  CB2  as  described  in  this  section.  Likewise,  if 
additional  channels  are  dropped  during  the  call  there  will  be  intermediate 
Phases  CD,  CE  as  described  in  §  3.4.4.  The  provisions  of  this  section  apply  to 
any  channel,  initial  or  additional,  for  which  Phases  B1  and  B2  have  been 
completed  and  Phase  D  not  yet  started. 

Mode  switching;  According  to  action  by  either  user  (for  example, 
starting  a  facsimile  machine)  a  different  mode  from  the  highest  common  mode  may 
become  more  appropriate.  Switching  to  this  mode  Is  made  according  to  the 
procedure  of  H.242. 

Capability  change:  The  user  may  change  the  capability  of  his  terminal 
during  the  call  (for  example,  by  connecting  or  svltchlng-on  auxiliary  Telematic 
equipment) ;  the  terminal  must  Initiate  the  capability  exchange  procedure  defined 
in  H.242. 

Phase  D  -  Termination  phase 
Phase  D1  (Terminal  procedure) 

When  one  of  the  users  hangs  up,  the  terminal  involves  Phase  D2 

directly. 

Phase  D2_(Mode  switching) 

Mode  OF  is  forced  according  to  H.242  (or  taking  into  account  the  result 
of  Phase  01  if  different,  for  further  study). 

Phase  E  -■  Call  termination  f release) 

The  terminal  which  has  initiated  the  hang  up  sends,  messages . over  the 
D-channel  with  respect  to  all  channels  and  idles  all  of  them  (that  means  no  more 
information  sent  over) . 

At  the  other  terminal,  the  first  disconnect  message  received  will  idle 
all  channels. 

The  actual  disconnection  occurs  at  reception  of  the  other  disconnect 
message (s) . 
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3.4.2  ExceoClonal  procedures  for  Phases  A  and  B 

In  case  of  unsuccessful  outcome  during  Phases  A  and  B  (due  to  many 
causes) ,  exceptional  procedures  are  provided  in  order  to  ensure  a  suitable 
service.  The  matter  is  for  further  study. 

3.4.3  Exceptional  procedures  during  Phase  C 

During  the  actual  exchange  of  audiovisual  data,  problems  may  occur  in 
some  channels.  Fallback  procedures,  managed  by  the  termiiial  are  activated.  The 
description  of  the  procedures  and  the  appropriate  indications  are  for  further 
study. 

3.4.4  Addition  and  dropping  of  channels  during  a  visual  telephone  call 
Addition 


According  to  action  by  a  user  (for  example  the  activation  of  auxiliary 
equipment)  one  or  more  additional  channels  are  requested.  The  procedure  follows 
those  described  for  Phases  CA  and  CBl. 

Dropping 

Two  phases  are  envisaged; 

Phase  GDI:  The  common  mode,  appropriate  to  the  channel(s)  which 
remains,  is  selected. 

Phase  CD2:  The  mode  switching  procedure  of  H.242  is  applied  to  involve 
the  mode  identified  in  Phase  CDl;  the  remaining  channel  is  the  channel 
used  for  initialization  (see  Phase  A).  It  supports  an  appropriate 
fallback  mode.  The  matter  is  for  further  study. 

3.4.5  Transmission  and  display  of  pictures  at  the  start  of  a  visual  telephone 
call 

According  to  the  chosen  terminal  procedures,  pictures  may  or  may  not  be 
visible  to  both  users  as  soon  as  initialization  is  complete.  In  the  case  that 
either  Phase  81-3  or  Phase  CBl *3  has  activated  a  common  mode,  including  video, 
mutual  visibility  of  the  users  is  possible. 

The  following  paragraphs  collect  alternative  procedures  which  can  be 
used  to  suspend  picture  display  until  user  Intervention  (by  mutual  agreement  or 
otherwise)  and  causes  pictures  to  be  displayed. 

1)  No  video  transmitted:  In  Phase  Bl*2  and  (if  relevant)  Phase  CBl-2 
the  mode  selected  includes  "video  OFF" .  During  Phase  C  either 
user  may  unilaterally  switch  to  "video  ON",  alternatively,  his 
terminal  may  send  the  C&I  BAS  code  VIR  (video  indicate  ready- to - 
activate) ,  but  not  switch  to  video-ON  until  VIR  is  also  received 
from  the  other  terminal.  While  the  incoming  video-OFF  state 
remains ,  the  visual  telephone  screen  should  display  a  symbol  or 
message  indicating  this  (i.e.  there  is  no  fault). 
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As  already  noted  in  §  3.4.1,  Phase  Bl-2,  the  request  for 
additional  channel  may,  according  to  terminal  procedure,  be 
delayed  while  video*OFF  is  maintained;  user  action  to  activate 
video  would  then  result  in  procedure  Phases  CAl,  CBl,  (CB2  if 
required) . 

2)  Video  pattern  transmitted;  An  electronically  generated  or  other 
pattern  is  transmitted  instead  of  the  signal  from  a  normal 
camera.  The  C&I  BAS  code  VIS  (video  indicate  suppressed)  is  used 
to  indicate  the  situation  to  the  remote  party. 

3)  Video  transmitted  but  not  displayed:  Terminal  procedures  simply 
Involve  local  action  to  display  not  the  Incoming  signal  but  an 
explanatory  symbol  or  message;  User  action  would  cause  the 
Incoming  signal  to  be  displayed,  but  If  this  should  depend  on 
mutvial  action  by  both  users  then  a  new  C&l  BAS  code  VRD  (video 
ready- to-display)  must  be  defined.  This  point  is  for  further 
study. 

3.5  Optional  enhancements 

3.5.1  Data  ports 

Data  ports  as  physical  I/O  ports  of  the  terminal  for  Telematic  and 
other  equipment  are  actlvated/deactlved  by  BAS  commands.  Depending  on  the 
transmission  capability  of  a  connection,  e.g.  multiples  of  B/HO  channels  etc., 
various  bit  rates  are  available  at  these  ports.  Allocation  of  bit  streams  to  the 
port(s)  is  performed  by  In-band  signalling.  Data  conveyed  at  the  port(s)  is 
transparent,  data  rates  being  listed  In  H.221,  Annex  1. 

3.5.2  Ensrypti9n 

Encryption  may  be  applied  on  audio  and  video  signals  separately 
(preferably  for  multipoint  connections)  or  on  audio  and  video  signals 
multiplexed.  Swltching-on  and  off  the  encryption  process  has  to  be  signalled 
between  the  terminals  (or  terminal  and  MCU  respectively)  via  in-band 
signalling. 

4.  Terminal  requirements 

4.1  Environments 

Under  study. 

4.2  Audio  and  video  arrangements 

Under  study. 

4.3  Delay  compensation  in  the  audio  path 

The  H.261  video  codecs  require  some  processing  delay,  while  the 
H. 200/AV. 250-Series  audio  codecs  involve  much  less  delay.  Hence,  if  lip 
synchronization  is  to  be  maintained,  that  video  processing  delay  must  be 
compensated  in  the  audio  path.  Since  video  coder  and  decoder  delays  may  vary 
according  to  implementation,  delay  compensation  must  be  carried  out  individually 
at  the  coder  and  decoder.  A  reference  measurement  method  of  video  coder  and 
decoder  delays  is  defined  in  Recommendation  H.261. 
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4.4  Control  and  Indications  (C&I) 

C&I  are  chosen  from  the  general  audiovisual  set  contained  in 
Recommendation  H.230.  For  visual  telephone  systems,  those  signals  in 
Table  4/H.320  are  used,  where  their  source,  sink,  synchronization  with  picture, 
transmission  channel  and  codewords  are  indicated. 

All  visual  telephone  terminals  have  a  video  source  providing  a  picture 
of  participants,  and  some  terminals  may  have  additional  video  sources;  the 
participant -picture  source  is  designated  //I,  having  the  associated  symbol  VIA. 
When  incoming  video  is  "ON"  (BAS  command  (010)  [1  or  2])  and  VIA,  VIA2,  VIA3 
have  not  been  transmitted,  source  #1  is  assumed. 

5.  Intercommunications 

The  mechanisms  for  intercommunication  with  other  services  are  described 
in  the  H.200/AV. 240 -Series. 

5.1  Intercommunication  between  different  visual  telephone  terminal  types 

A  common  mode  of  operation  is  determined  as  described  in  §  3.4.1  above. 
D-channel  signalling  should  include  new  LLC  and  HLC  which  are  appropriate  for 
audiovisual  services,  but  this  point  is  for  further  study. 

5.2  Intercommunication  with  telephony 

Note  -  Description  of  this  section  is  for  communications  using  a  B*channel. 

5.2.1  Intercommunication  with  ISDN  telephones 

A  call  from  a  visual  telephone  to  an  ISDN  telephone  is  first  placed  as 
an  audiovisual  call,  but  the  ISDN  telephone  returns  "Incompatible  destination" 
or  the  network  returns  "Recovery  on  timer  expiry"  in  case  of  no  responses  from 
the  called  side,  then  the  visual  telephone  may  switch  to  a  speech  or  7  kHz  audio 
bearer  service  call. 

A  call  from  ISDN  telephone  to  a  visual  telephone  is  accepted  by  the 
visual  telephone  becaxise  every  audiovisual  terminal  is  equipped  with  this 
telephone  capability  as  a  minimum  function. 

For  both  of  the  above  cases ,  the  operational  mode  of  communication  is 
G.711  speech  or  G.722  audio. 

5.2.2  Intercoimmini ration  with  PSTN  telephones 

A  call  from  visual  telephone  to  a  PSTN  telephone  may  be  initiated  as  an 
audiovisual  call,  but  the  network  returns  "No  route  to  destination",  then  the 
visual  telephone  may  switch  to  a  speech  or  3.1  kHz  audio  bearer  service  call. 

The  operational  mode  of  communication  is  G.711  audio  coding.  A  call  from  a  PSTN 
telephone  is  routed  into  the  ISDN  as  a  3.1  kHz  audio  call  which  can  be  responded 
by  the  visual  telephone  for  the  same  reason  as  described  in  §  5.2.1.  The 
operational  mode  of  communication  is  3.1  kHz  audio. 

5.3  Intercommunication  with  other  audiovisual  terminals 

A  common  mode  of  operation  is  determined  according  to  H.242. 
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6.  Maintenance 

Some  loop'back  functions  are  envisaged  to  allow  verification  of  Che 
functional  aspects  of  the  terminal  in  order  to  ensure  correct  operation  of  the 
system  and  satisfactory  quality  of  the  service  to  the  remote  party.  The 
following  loop-back  functions  (see  Figure  2/H.320)  are  envisaged: 

Loop  at  terminal -network  interface  (towards  network) 

Upon  receiving  the  "digital  loop  back"  BAS,  loop  back  is 
activated  at  Che  digital  interface  of  Che  terminal  toward  the 
network  side.  In  case  of  a  multiple  B/HO  channel  arrangement, 
loop  back  is  activated  in  each  connection. 

Loop  at  terminal -network  interface  (towards  terminal) 

The  procedure  is  for  further  study. 

Loop  at  analogue  I/O  interface 

Upon  receiving  the  "video  loop  back"  or  "audio  loop  back"  BAS, 
loop  back  is  activated  at  Che  analogue  Interface  of  the 
video/audio  codec  towards  the  video/audio  codec. 

The  opportunity  of  having  a  self-checking  procedure  at  terminal  stage 
is  for  further  study. 

7.  Human  factor  aspects 

To  achieve  error  free  and  uncomplicated  utilization  of  terminal 
equipment  and  service  from  the  users  standpoint,  human  factor  related  aspects 
have  Co  be  studied  and  recommended.  These  aspects  deal  with  the  flow  of 
information  between  user  and  terminal/network.  This  information  can  be  divided 
into  a  physical  section  and  a  logical  section  of  the  MHI. 

Physical  section 

Figures  and  properties  of  transducers  (camera,  microphone,  etc.). 
Signals  particularly  related  to  the  service,  keys,  pictograms. 


Procedures,  e.g.  for  call  establishment/release ,  during 
communication  phase. 

Consistency  between  the  MMIs  of  visual  telephone  and  terminals  of 
other  teleservices. 


* 
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H.320 


Terminal  Equipment  T1S02490-90 

MCU:  Multipoint  Control  Unit 


FIGURE  1/H.320 
Visual  telephone  system 


Normal 


Digital  Loop  Request  (LCD) 


Audio/Video  Loop  Request  (LCA/LCV) 

FIGURE  2/H.320 
Loop  back 
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TABLE  1/H.320 

Communication  modes  of  visual  telephone 


Visual 
Telephone 
Mode 
(Note  1) 

Channel 

ISDN  Interface 

Coding 

Rate 

(kbit/s) 

Channel 
(Note  2) 

Basic 

Primary 

Rate 

Audio 

Video 

a 

aO 

al 

64 

B 

G.711 

not 

applicable 

H. 200/AV. 254 

bl 

G.711 

b 

b2 

128 

2B 

G.722 

b3 

H. 200/AV. 254 
/253 

(Note  1) 

c 

198 

3B 

d 

256 

4B 

e 

320 

5B 

f 

384 

6B 

H.261 

g 

384 

HO 

applicable 

h 

768 

2H0 

not 

applicable 

1 

1152 

3H0 

G.722 

j 

1536 

3H0 

k 

1536 

Hll 

1 

1920 

5H0 

m 

1920 

H12 

Note  1  -  (Audio  coding  of  mode  b3}  In  addition  to  H. 200/AV. 254,  higher  quality 
audio  coding  such  as  H. 200/AV. 253  may  be  used  for  this  mode. 

Note  2  -  For  multiple  channels  of  B/HO,  all  channels  are  synchronized  at  the 
terminal  according  to  §  2.7/H.221. 
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aO  B( audio  only) 


al  B(H.200/AV.254  audio)  X  X  X  X 


bl  2B(G.711  audio)  XXX 


b2  2B(G.722  audio) 


b3  2B (H . 200/AV . 254  audio ) 


c  3B 


4B 


e  5B 


f  6B 


g  HO 


2H0 


3H0 


J  4H0 


Hll 


5H0 


H12 


Type  X  (Noce  2) 


a  bl  b2  b3  b4  b5  c  d  e  f  1  2  3 


XXXXXXXXXX 


X  X  X  X 


Type  Z 


6 


XXXXXXXXX 


XX  X  X  X  X  X 


X  X  X  X 


X  X  X  X 


XXX 


X 


X 

X 

X 

X 

X 

X 

X 

X 

Note  1  •  "X”  means  the  mode  is  equipped  with  the  terminal  of  the  type. 

Note  2  •  Types  Xb4  and  Xb5  are  defined  to  take  into  account  that  H. 200/AV. 254  has 
not  yet  been  recommended. 

Note  3  -  Terminal  of  this  type  must  have  the  H0-6B  compatible  mode  defined  in 
Recommendation  H.221. 
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FOREWORD 


This  standard  is  issued  by  the  General  Services  Administration 
pursuant  to  the  Federal  Property  and  Administrative  Services  Act 
of  1949,  as  amended. 

This  document  provides  Federal  departments  and  agencies  a 
comprehensive  description  of  the  performance  and  interoperability 
criteria  for  video  coders  and  decoders  (codecs)  used  in  video 
teleconferencing  and  video  phone  applications.  This  standard  was 
developed  within  the  Federal  Telecommunication  Standards  Committee 
(FTSC) .  Standard  development  was  based  on  the  requirements 
contained  in  the  Statement  of  Requirements  (SOR)  for  the 
development  of  a  standard  for  digital  transmission  of  video 
teleconferencing . 

This  standard  shall  be  used  by  all  Federal  departments  and 
agencies  in  the  design  and  procurement  of  codecs  used  in  video 
teleconferencing  and  video  phone  applications.  Neither  this  nor 
any  other  standard  in  high  technology  field  such  as 
telecommunications  can  be  considered  complete  and  ageless. 

Periodic  revisions  will  be  made  as  required. 

This  standard  is  technically  equivalent  to  CCITT  Recommendation 

H. 261  (1990)  and  ANSI  Tl.p64x  (199x) .  The  following  areas  have 
been  changed  or  added  to  H.261  to  meet  the  needs  of  the  Federal 
(Government:  Sections  1,  2,  3,  4,  5,  7.2.2,  9.4.1.  In  addition  to 
these  section  changes,  editorial  changes  have  been  made  to  reflect 
common  english  (e.g.  change  colour  to  color). 

Recommendation  H.261  specifies  service  from  64  )cbit/s  through 

I, 920  kbit/s,  and  ANSI  standard  Tl.p64*'199x  specifies  service  from 
56  kbit/s  through  1,536  kbit/s.  To  avoid  confusion  on 
applications  within  the  Federal  Government  involving  both  national 
and  international  interoperability,  this  standard  encompasses  both 
ranges  of  data  rates  to  specify  service  from  56  kbit/s  through 
1,920  kbit/s.  It  should  be  noted  that  most  standard  data  networks 
in  the  United  States  carry  data  from  56  kbit/s  to  1,536  kbit/s. 

The  digitally  encoded  video  specified  by  these  standard  is 
intended  to  be  used  with  CCITT  Recomnendations  H.221,  Frame 
Structure  for  a  64  to  1920  kbit/s  channel  in  Audiovisual 
Teleservices;  H.242,  System  for  Establishing  Communication  Between 
Audiovisual  Terminals  using  Digital  Channels  up  to  2  Mbit/s;  and 
H.230,  Frame-Synchronous  Control  and  Indication  Signals  for 
Audiovisual  Systems.  It  is  intented  to  adopt  these 
reconmendations  into  Federal  Standards.  Titles  and  application 
for  Federal  use  is  yet  to  be  determined. 
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TELECOMMUNICATIONS : 

VIDEO  CODER/DECODER  FOR  AUDIOVISUAL 
SERVICES  AT  56  TO  1,920  KBIT/S 


1.  Scop«,  Puxposa,  and 
Application 

1.1  Scop*.  This  standard 
describes  the  video  coding  and 
decoding  methods  for  the  moving 
picture  component  of  audiovisual 
service  at  the  rates  of  56  to 
1,920  kbit/s.  Included  are 
specifications  for  the  video 
source  format,  the  source  coding 
algorithm,  the  video  multiplex 
arrangement,  and  the  forward 
error  correction  code.  This 
standard  is  technically 
equivalent  to  CCITT 
Recommendation  H.261  (1990) . 

1.2  Puzpos*.  The  purpose  of 
this  document  is  to  improve  the 
Federal  acquisition  process  by 
providing  Federal  departments  and 
agencies  a  comprehensive, 
authoritative  source  for  video 
coders  and  decoders  (codecs)  used 
in  video  teleconferencing  and 
video  phone  applications.  The 
technical  parameters  of  this 
document  may  be  exceeded  in  order 
to  satisfy  certain  specific 
requirements,  provided  that 
interoperability  is  maintained. 
That  is,  the  capability  to 
incorporate  features  such  as 
additional  standard  and 
nonstandard  interfaces  is  not 
precluded. 

1.3  Application.  This 
standard  is  intended  to  assure 
interoperability  among  Federal 
video  teleconferencing  and  video 
phone  systems  employing  video 
codecs  at  rates  between  56  kbit/s 
and  1,920  kbit/s. 

Two  categories  of  applications 
are  defined  for  Federal  use.  The 
specifications  defined  below  are 
a  minimum  for  each  category. 

Category  1  is  for  service  that  is 
limited  to  lower  data  rates,  such 
as  provided  by  a  basic  rate 


Integrated  Services  Digital 
Network  (ISDN) .  Examples  of  uses 
are  video  telephone  or 
surveillance  type  services. 

Codecs  acquired  for  Category  1 
applications  will  be  capable  of 
operation  at  56  kbit/s  and  64 
kbit/s  (p-1) ,  and  optionally  at 
112  kbit/s  and  128  kbit/s  (p~2) , 
using  Quarter  Common  Intermediate 
Format  (QCIF) . 

Category  2  is  for  service 
requiring  higher  quality  than 
Category  1  such  as  needed  for 
full  video  teleconferencing. 
Codecs  acquired  for  Category  2 
applications  will  contain  the 
functionality  of  Category  1 
codecs,  plus  at  a  minimum,  be 
capable  of  operation  at  128,  192, 
256,  and  384  kbit/s 
(p*2, 3, 4, 5, 6) .  All  category  2 
codecs  must,  at  a  minimum,  be 
capable  of  operation  at  Full 
Common  Intermediate  Format  (CIF) 
at  rates  equal  to  or  above  128 
kbit/s. 

1.3.1  The  digitally  encoded 
video  is  intended  to  be 
transmitted  within  the  frame 
structure  described  in  CCITT 
Recommendation  H.221  for 
narrowband  audiovisual  services. 
This  frame  structure  multiplexes 
subchannels  for  audio,  video, 
data,  and  telematic  transmission, 
as  well  as  in-channel  terminal- 
to-terminal  signalling 
information,  within  an  overall 
transmission  channel  of  56  to 
1,920  kbit/s. 

In  an  ISDN,  the  overall 
transmission  channel  may  consist 
of  1  to  6  B  (64  kbit/s)  channels, 
1  to  4  HO  (384  kbit/s)  channels, 
an  HIO  (1,472  kbit/s)  channel,  or 
an  Hll  (1,536  kbit/s)  channel. 

The  framed  video  signal  can  also 
be  carried  on  other  switched  or 
dedicated  digital  transmission 
facilities,  such  as  1  to  6  56 
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kbit/s  connections,  a  OSl 
connection,  or  a  fractional  DSl 
connection.  The  H.221  frame 
structure  provides  for  the 
synchronization  of  multiple 
connections . 

NOTE:  The  video  coding  algorithm 
described  in  this  standard  is  a 
variable-rate  algorithm,  video 
transmission  is  not  fixed  at 
multiples  of  56  or  64  kbit/s,  but 
instead  occupies  whatever 
bandwidth  allocated  for  video 
within  an  overall  audiovisual 
communications  system.  "Px64 
kbit/s"  are  the  nominal 
transmission  rates  of  the  overall 
system.  CCZTT  Recommendation 

H. 221  provides  for  operating  at 
multiples  of  56  and  64  kbit/s. 

CCZTT  Recommendation  H.242 
describes  the  in-channel 
terminal-to-terminal 
communication  control  procedures. 
These  procedures  allow 
audiovisual  terminals  with 
different  capabilities  to 
interwork  with  each  other  and 
with  existing  telephone 
equipment.  These  procedures  also 
allow  terminals  to  switch  among 
coir^atible  modes  of  operation  to 
support  additional  applications, 
for  example,  sending  a  facsimile 
or  connecting  two  personal 
computers . 

Additional  frame-synchronous 
control  and  indication  signals 
such  as  freeze  picture,  video 
loopback,  and  simple  multipoint 
controls  are  described  in  CCZTT 
Recommendation  H.230. 

I. 3.2  This  standard  shall  be 
used  by  all  Federal  departments 
and  agencies  in  the  design  and 
procurement  of  video 
teleconferencing  and  video  phone 
systems  employing  video  codecs. 
This  standard  is  mandatory  only 
for  those  video  codecs  operating 
at  rates  between  56  kbit/s  and 
1,920  kbit/s.  The  standard  shall 
be  used  in  the  planning,  design, 
and  procurement,  including  lease 
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and  purchase,  of  all  new  video 
communications  systems  that 
utilize  video  codecs.  It  is  not 
intended  that  existing  equipment 
and  systems  be  immediately 
converted  to  comply  with  the 
provisions  of  this  standard.  New 
equipment  and  systems  and  those 
undergoing  major  modification  or 
rehabilitation  shall  conform  to 
this  standard. 

1.3.3  For  application  of  this 
standard  within  the  Department  of 
Defense,  users  should  refer  to 
the  supplemental  requirements 
contained  in  Military  Standard 
188-131. 

2.  Effective  Date.  The  use  of 
this  standard  by  U.S.  government 
departments  and  agencies  is 
mandatory,  effective  180  days 
following  the  date  of  this 
standard. 

3.  Changes.  When  a  Government 
department  or  agency  considers 
that  this  standard  does  not 
provide  for  its  essential  needs, 
a  statement  citing  specific 
requirements  shall  be  sent  in 
duplicate  to  the  General  Services 
Administration  (K) ,  Washington, 

DC  20405,  in  accordance  with  the 
provisions  of  Federal  Property 
Management  Regulation  41  CFR  101- 
29.403.1.  The  General  Services 
Administration  will  determine  the 
appropriate  action  to  be  taken 
and  will  notify  the  agency. 

PREPARING  ACTIVITY: 

National  Communications  System 
Office  of  Technology  and 
Standards 

Washington,  DC  20305-2010 

4 .  Referenced  and  Related 
Standards 

4 . 1  Referenced  Standards . 

This  standard  is  intended  for  use 
in  conjunction  with  the  following 
standards : 
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CCIR  Reconsnendation  601-1, 


Encoding  Parameters  of  digital 

ANSI 

American  National 

Television  for  Studios, 

Standards  Institute 

Recommendations  and  Reports  of 

BCH 

Bose-Chaudhuri- 

the  CCIR,  Volume  XI,  Part  1,  1986 

Hocquenghem 

CBP 

Coded-Block  Pattern 

CCITT  Recommendation  H.221,  Frame 

CCIR 

International  Radio 

Structure  for  a  64  to  1,920 

Consultative 

kbit/s  Channel  in  Audiovisual 

Committee 

Teleservices,  1990 

CCITT 

International 
Telegraph  and 

CCITT  Recommendation  H.230, 

Telephone 

Frame-Synchronous  Control  and 

Consultative 

Indication  Signals  for 

Committee 

Audiovisual  Systems,  1990 

CIF 

Common  Intermediate 
Format 

CCITT  Recommendation  H.242, 

CODEC 

Coder/Decoder 

System  for  Establishing 

DCT 

Discrete  Cosine 

Communication  Between  Audiovisual 

Transform 

Terminals  Using  Digital  Channels 

EOB 

End  of  Block 

up  to  2  Mbit/s,  1990 

FIL 

Loop  Filter 

FLC 

Fixed  Length  Code 

4 . 2  Related  Standards .  The 

GBSC 

Group  of  Blocks  Start 

standards  listed  here  are  for 

Code 

information  only  and  are  not 

GEI 

GOB  Extra  Insertion 

essential  for  the  completion  of 

information 

the  requirements  of  this 

GN 

Group  Number 

standard. 

GOB 

Group  of  Blocks 

GQUANT 

GOB  Quantizer 

ANSI  Tl. 306-1990,  American 

information 

National  Standard  for 

GSPARE 

GOB  Spare  information 

Telecommunications  -  Digital 

HRD 

Hypothetical 

Processing  of  Audio  Signals  - 

Reference  Decoder 

Algorithm  and  Line  Format  for 

IDCT 

Inverse  Discrete 

Transmission  of  7-kHz  Audio 

Cosine  Transform 

Signals  at  64/56  kbit/s 

INTER 

Inter-picture 

prediction 

ANSI  Tl.p64-199x,  American 

INTRA 

Intra-picture 

National  Standard  for 

prediction 

Telecommunications  -  video 

MB 

Macroblock 

Coder/Decoder  for  Audiovisual 

MBA 

Macroblock  Address 

Services  at  56  to  1,536  kbit/s 

MC 

Motion  Compensation 

MQUANT 

Macroblock  Quantizer 

CCITT  Recommendation  N.261,  video 

MTYPE 

Macroblock  Type 

Codec  for  Audiovisual  Services  at 

information 

px64  kbit/s,  1990 

MVD 

Motion  Vector  Data 

PEI 

Picture  Extra 

CCITT  Recommendation  H.320, 

Insertion  information 

Narrowband  Visual  Telephone 

PSC 

Picture  Start  Code 

Systems  and  Terminal  Equipment, 

PSPARE 

Picture  Spate 

1990 

information 

PTYPE 

Picture  Type 

MlL-STD-188-131,  Video  Codec 

information 

Equipment  for  Video 

QCIF 

Quarter-CIF 

Teleconferencing  Applications, 

QUANT 

Quantizer 

1990 

REC 

Reconstruction  level 

TCOEFF 

Transform  Coefficient 

5 .  Abbreviations 

TR 

Temporal  Reference 
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VLC  Variable  Length  Code 

6 .  Brief  Specification 


An  outline  block  diagram  o£  the 
codec  is  given  in  Figure  1. 


I - 1 


rigure  1 


Outline  block  diagram 


6 . 1  Video  Input  and  Output . 
To  permit  a  single  recommendation 
to  cover  use  in  and  between 
regions  using  625  and  525  line 
television  standards,  the  source 
coder  operates  on  pictures  based 
on  a  common  intermediate  format 
(CIF) .  The  standards  of  the  input 
and  output  television  signals, 
which  may,  for  example,  be 
composite  or  component,  analogue 
or  digital  and  the  methods  of 
performing  any  necessary 
conversion  to  and  from  the  source 
coding  format  are  not  subject  to 
recommendation . 

6.2  Digital  Output  and 
Input.  The  video  coder  provides 
a  self-contained  digital  bit 


of  the  video  codec 

stream  which  may  be  combined  with 
other  multi-facility  signals  (for 
example  as  defined  in  Rec. 

H.221).  The  video  decoder 
performs  the  reverse  process. 

6.3  Saa^ling  Frequency. 
Pictures  are  sampled  at  an 
integer  multiple  of  the  video 
line  rate.  This  sampling  clock 
and  the  digital  network  clock  are 
asynchronous . 

6.4  Source  Coding  Algorithm. 
A  hybrid  of  inter-picture 
prediction  to  utilize  temporal 
redundancy  and  transform  coding 
of  the  remaining  signal  to  reduce 
spatial  redundancy  is  adopted. 

The  decoder  has  motion 
compensation  capability,  allowing 
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6.5  Bit  Rat*.  This 
Recommendation  is  primarily 
intended  for  use  at  video  bit 
rates  between  approximately  40 
kbit/s  and  2  Mbit/s. 

6 . 6  Synaatry  o£ 

Transmission.  The  codec  may 
be  used  for  bidirectional  or 
unidirectional  .visual 
communication . 

6.7  Brsos  Handling.  The 
transmitted  bit-stream  contains  a 
BCH(511,493)  Forward  Error 
Correction  code.  Use  of  this  by 
the  decoder  is  optional. 

6.8  Multipoint  Operation. 
Features  necessary  to  support 
switched  multipoint  operation  are 
included. 

7 .  Source  Coder 

7.1  Source  Format.  The  source 
coder  operates  on  non-interlaced 
pictures  occurring  30000/1001 
(approximately  29.97)  times  per 
second.  The  tolerance  on  picture 
frequency  is  +/-S0  ppm. 

Pictures  are  coded  as  luminance 
and  two  color  difference 
components  (Y,  Cb  and  Cr) .  These 
components  and  the  codes 
representing  their  sampled  values 
are  defined  in  CCZR 
Recommendation  601. 

Black  -  16 
White  -  235 

Zero  color  difference  -  128 
Peak  color  difference  •  16  and  240 

These  values  are  nominal  ones  and 
the  coding  algorithm  functions 
with  input  values  of  1  through  to 
254.  See  table  6. 

Two  picture  scanning  formats  are 
specified. 

In  the  first  format  (CZF) ,  the 
luminance  sampling  structure  is 
352  pels  per  line,  288  lines  per 
picture  in  an  orthogonal 
arrangement.  Sampling  of  each  of 
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the  two  color  difference 
components  is  at  176  pels  per 
line,  144  lines  per  picture, 
orthogonal.  Color  difference 
samples  are  sited  such  that  their 
block  boundaries  coincide  with 
luminance  block  boundaries  as 
shown  in  Figure  2 .  The  picture 
area  covered  by  these  numbers  of 
pels  and  lines  has  an  aspect 
ratio  of  4:3  and  corresponds  to 
the  active  portion  of  the  local 
standard  video  input. 

Note:  The  number  of  pels  per  line 
is  compatible  with  sampling  the 
active  portions  of  the  luminance 
and  color  difference  signals  from 
525  or  625  line  sources  at  6.75 
and  3.375  MHz  respectively. 

These  frequencies  have  a  simple 
relationship  to  those  in  CCIR 
Recommendation  601. 

The  second  format,  Quarter-CIF 
((2CIF) ,  has  half  the  number  of 
pels  and  half  the  number  of  lines 
stated  above.  Ml  codecs  must  be 
able  to  operate  using  QCIF.  Some 
codecs  can  also  operate  with  CIF. 

Means  shall  be  provided  to 
restrict  the  maximum  picture  rate 
of  encoders  by  having  at  least  0, 
1,  2,  or  3  non-transmitted 
pictures  between  transmitted 
ones.  Selection  of  this  minimum 
number  and-  CIF  or  QCIF  shall  be 
by  external  means  (for  example 
via  Recommendation  H.221). 
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X  LUMINANCE  SAMPLE 
°  CHROMINANCE  SAMPLE 
BUXKEDGE 


rigur*  2 

Poaltlonlng  o£  lualnanca  and 
chromlnanca  samplaa 

7 . 2  Vldao  Sourea  Coding 
Algorithm.  The  source  coder  is 


shown  in  generalized  form  in 
Figure  3.  The  main  elements  are 
prediction,  block  transformation, 
and  quantization. 

The  prediction  error  (INTER  mode) 
or  the  input  picture  (INTRA  mode) 
is  subdivided  into  8  pel  by  8  pel 
line  blocks  which  are  segmented 
as  transmitted  or  non- 
transmitted.  Further,  four 
luminance  blocks  and  the  two 
spatially  corresponding  color 
difference  blocks  are  combined  to 
form  a  macroblock  as  shown  in 
Figure  10  of  8.2.4. 

The  criteria  for  choice  of  mode 
and  transmitting  a  block  are  not 
subject  to  recommendation  and  may 
be  varied  dynamically  as  part  of 
the  coding  control  strategy. 
Transmitted  blocks  are 
transformed  and  resulting 
coefficients  are  quantized  and 
variable  length  coded. 
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T  Transform 

Q  Quantizer 

P  Picture  Memory  with  motion  compensation  variable  delay 
F  Loop  filter 

CC  Coding  control 

p  Flag  for  INTRA/ INTER 

t  Flag  for  transmitted  or  not 

qz  Quantizer  indication 

q  Quantizing  index  for  transform  coefficients 

V  Motion  vector 

f  Switching  on/off  of  the  loop  filter 


rigure  3 
Source  codoc 


7.2.1  P  codlct  Ion .  The 
prediction  is  inter-picture  and 
may  be  augmented  by  motion 
compensation  (see  7.2.2)  and  a 
spatial  filter  (see  7.2.3). 

7.2.2  Motion  Coapansatlon . 
Motion  Compensation  (MC)  is 
optional  in  the  encoder,  but  will 
be  considered  in  evaluating  the 
price-performance  characteristics 
of  collating  vendor  proposals. 

The  decoder  will  accept  one 
vector  per  macrobloc)c.  Both 
horizontal  and  vertical 
components  of  these  motion 
vectors  have  integer  values  not 
exceeding  +/-15.  The  vector  is 
used  for  all  four  luminance 
blocks  in  the  macrobloc)c.  The 
motion  vector  for  both  color 
difference  bloc)cs  is  derived  by 
halving  the  component  values  of 
the  macroblock  vector  and 
truncating  the  magnitude  parts 
toward  zero  to  yield  integer 
components . 


7.2.3  X,oop  niter.  The 
prediction  process  may  be 
modified  by  a  two-dimensional 
spatial  filter  (FIL)  which 
operates  on  pels  within  a 
predicted  8  by  8  block.  The 
filter  is  separable  into  one 
dimensional  horizontal  and 
vertical  functions.  Both  are 
non-recursive  with  coefficients 
of  1/4,  1/2,  1/4  except  at  block 
edges  where  one  of  the  taps  would 
fall  outside  the  block.  In  such 
cases  the  1-D  filter  is  changed 
to  have  coefficients  of  0,  1,  0. 
Full  arithmetic  precision  is 
retained  with  rounding  to  8  bit 
integer  values  at  the  2-D  filter 
output.  Values  whose  fractional 
part  is  greater  or  equal  to  one 
halt  are  rounded  up. 

The  filter  is  switched  on/off  for 
all  6  blocks  in  a  macroblock 
according  to  the  macroblock  type. 
(See  8.2.3  MTYFE) . 


A  positive  value  of  the 
horizontal  or  vertical  component 
of  the  motion  vector  signifies 
that  the  prediction  is  formed 
from  pels  in  the  previous  picture 
which  are  spatially  to  the  right 
or  below  the  pels  being 
predicted. 

Motion  vectors  are  restricted 
such  that  all  pels  referenced  by 
them  are  within  the  coded  picture 
area. 


7.2.4  Transformer. 

Transmitted  blocks  are  first 
processed  by  a  separable  2- 
dimensional  Discrete  Cosine 
Transform  of  size  8  by  8 .  The 
output  from  the  inverse  transform 
ranges  from  -256  to  +255  after 
clipping  to  be  represented  with  9 
bits.  The  transfer  function  of 
the  inverse  transform  is  given 
by: 
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f(x,y)  -  1/4 


7  7 


C(u)  C(v)  F(u,v)  cos(Pi(2x+1)u/16]  cos[Pi(2y+1)v/16] 


u»0  v-0 


with  u,  V,  X,  y  “  0,  1,  2,  7 

where  x,y  -  special  coordinates  in  the  pel  domain 
u,  V  >  coordinates  in  the  transform  domain 
C(u)  1/SQRT(2)  for  u  »  0,  otherwise  1. 

C(v)  =  1/SQRT(2)  for  v  =  0,  otherwise  1. 

Note:  Within  the  block  being  transformed,  x~0  and  y  •>  0  refer  to  the 
pel  nearest  the  left  and  top  edges  of  the  picture  respectively. 


The  arithmetic  procedures  for 
computing  the  transforms  are  not 
defined,  but  the  inverse 
transform  shall  meet  the  error 
tolerance  specified  in  section 
10. 

7.2.5  Quantization .  The 

number  of  quantizers  is  1  for  the 
INTRA  DC  coefficient  and  31  for 
all  other  coefficients.  Within  a 
macroblock  the  same  quantizer  is 
used  for  all  coefficients  except 
the  INTRA  DC  one.  The  decision 
levels  are  not  defined.  The 
INTRA  DC  coefficient  is  nominally 
the  transform  value  linearly 
quantized  with  a  stepsize  of  8 
and  no  dead-zone.  Each  of  the 
other  31  quantizers  is  also 
nominally  linear  but  with  a 
central  dead-zone  around  zero  and 
with  a  stepsize  of  an  even  value 
in  the  range  2  to  62. 

The  reconstruction  levels  are  as 
defined  in  8.2.4. 

Note:  For  the  smaller 
quantization  step  sizes,  the  full 
dynamic  range  of  the  transform 
coefficients  cannot  be 
represented. 

7.2.6  Clipping  of 
Reconstructed  Picture.  To 
prevent  quantization  distortion 
of  transform  coefficient 
amplitudes  causing  arithmetic 
overflow  in  the  encoder  and 
decoder  loops,  clipping  functions 
are  inserted.  The  clipping 


function  is  applied  to  the 
reconstructed  picture  which  is 
formed  by  summing  the  prediction 
and  the  prediction  error  as 
modified  by  the  coding  process. 
This  clipper  operates  on 
resulting  pel  values  less  than  0 
or  greater  than  255,  changing 
them  to  0  and  255  respectively. 

7.3  Coding  Control.  Several 
parameters  may  be  varied  to 
control  the  rate  of  generation  of 
coded  video  data.  These  include 
processing  prior  to  the  source 
coder,  the  quantizer,  block 
significance  criterion  and 
temporal  subsampling.  The 
proportions  of  such  measures  in 
the  overall  control  strategy  are 
not  subject  to  recommendation. 

When  invoked,  temporal 
subS2unpling  is  performed  by 
discarding  complete  pictures. 

7.4  Forced  Updating.  This 
function  is  achieved  by  forcing 
the  use  of  the  INTRA  mode  of  the 
coding  algorithm.  The  update 
pattern  is  not  defined.  For 
control  of  accumulation  of 
inverse  transform  mismatch  error 
a  macroblock  should  be  forcibly 
updated  at  least  once  per  every 
132  times  it  is  transmitted. 

8 .  Video  Multiplex  Codec 

8.1  Data  Structure.  Unless 
specified  otherwise  the  most 
significant  bit  is  transmitted 
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first.  This  is  Bit  1  and  is  the 
leftmost  bit  in  the  code  tables 
in  this  document.  Unless 
specified  otherwise  all  unused  or 
spare  bits  are  set  to  Spare 

bits  must  not  be  used  until  their 
functions  are  specified  by  CCITT. 

8 . 2  Video  Multiplex 
Arxengeiaent .  The  video 
multiplex  is  arranged  in  a 
hierarchical  structure  with  four 


layers.  From  top  to  bottom  the 
layers  are: 

Picture 

Group  of  Blocks  (GOB) 
Macroblock  (MB) 

Block 

A  syntax  diagram  of  the  video 
multiplex  coder  is  shown  in 
Figure  4.  Abbreviations  are 
defined  in  section  5  and  in  later 
sections. 


PICTURE  LAYER 


MB  LAYER 
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BLOCK  LAYER 


Rxed  length 
Variable  length 


Figure  4 

Syntax  diagram  for  the  video  multiplex  coder 


8.2.1  Picture  Layer .  Data 
for  each  Picture  consiats  of  a 
Picture  Header  followed  by  data 
for  GOBs.  The  structure  is  shown 
in  Figure  5.  Picture  Headers  for 
dropped  pictures  are  not 
transmitted. 

Picture  Start  Code  (PSC) :  20  bits 

A  word  of  20  bits.  Its  value  is 
0000  0000  0000  0001  0000 

Temporal  Reference  (TR) :  5  bits 

A  five  bit  number  which  can  have 
32  possible  values.  It  is  formed 
by  incrementing  its  value  in  the 
previously  transmitted  Picture 
Header  by  1  plus  the  number  of 
non- transmitted  pictures  (at 
29.97  Hz)  since  that  last 
transmitted  one.  The  arithmetic 
is  performed  with  only  the  5 
LSBs. 


Extra  Insertion  Information 
(PEI) :  1  bit 

A  bit  which  when  set  to  ' 1 ' 
signals  the  presence  of  the 
following  optional  data  field. 

Spare  Information  (PSPARE) : 
0/8/16. . .bits 

If  PEI  is  set  to  '1',  then  9  bits 
follow  consisting  of  8  bits  of 
data  (PSPARE)  and  then  another 
PEZ  bit  to  indicate  if  a  further 
9  bits  follow  and  so  on. 

Encoders  must  not  insert  PSPARE 
until  specified  by  CCITT. 

Decoders  must  be  designed  to 
discard  PSPARE  if  PEI  is  set  to 
1.  This  will  allow  CCITT  to 
specify  future  "backward" 
compatible  additions  in  PSPARE. 


Type  Information  (PTYPE) :  6  bits 

Information  about  the  complete 
picture; 

Bit  1  Split  screen  indicator. 

•O'  off.  '1'  on. 

Bit  2  Document  camera  indicator. 

•O'  off,  '1'  on. 

Bit  3  Freeze  Picture  Release. 

•O'  off,  '1'  on. 

Bit  4  Source  Format. 

•O'  QCIF,  '!•  CIF. 

Bits  5  to  6  Spare. 
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1  1 


I 

I 


TR 


*  PTYPE 

I 


Figure  5 

Structure  of  Picture  layer 


8.2.2  Group  of  Blocks  Layer . 

Each  picture  is  divided  into 
Groups  of  Blocks  (GOBs) .  A  group 
of  blocks  (GOB)  comprises  one 
twelfth  of  the  GIF  or  one  third 
of  the  QCIF  picture  areas  (see 
Figure  6) .  A  GOB  relates  to  176 
pels  by  48  lines  of  Y  and  the 
spacially  corresponding  88  pels 
by  24  lines  of  each  of  Cb  and  Cr. 

Data  for  each  Group  of  Blocks 
consists  of  a  (^B  Header  followed 
by  data  for  macroblocks.  The 
structure  is  shown  in  Figure  7. 
Bach  GOB  Header  is  transmitted 
once  between  Picture  Start  Codes 
in  the  GIF  or  QCIF  sequence 
numbered  in  Figure  6,  even  if  no 
macroblock  data  is  present  in 
that  GOB. 


GIF  C3C1F 


Figure  6 

Arrangement  of  (SOBa  in  a 
Picture 


["gBScI  0^  "IgCXJANtI  gs  [  ^  ^gspare|  I  ^  1 

Figure  7 

structure  of  Group  of  Blocks  Layer 


Group  of  Blocks  Start  Code 
(GBSC) :  16  bits 

A  word  of  16  bits*  0000  0000  0000 

0001. 

Group  Number  (GN) :  4  bits 

Four  bits  indicating  the  position 
of  the  groups  of  blocks.  The 
bits  are  the  binary 
representation  of  the  numbers  in 
Figure  6.  Group  niunbers  13,  14 
and  15  are  reserved  for  future 
use.  Group  number  0  is  used  in 
the  PSC. 


Quantizer  Information  (GQUANT) : 

5  bits 

A  fixed  length  of  codeword  of  S 
bits  which  indicates  the 
quantizer  to  be  used  in  the  group 
of  blocks  until  overridden  by  any 
subsequent  MQUANT.  The  codewords 
are  the  natural  binary 
representations  of  the  values  of 
QUANT  (see  8.2.4.)  which,  being 
half  the  stepsizes,  range  from  1 
to  31. 

Extra  Insertion  Information 
(GEX) :  1  bit 
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macroblocks  as  shown  in  Figure  8 . 
A  macroblock  relates  to  16  pels 
by  16  lines  of  Y  and  the 
spatially  corresponding  8  pels  by 
8  lines  of  each  of  Cg  and  Cr. 


If  GEI  is  set  to  '1',  then  9  bits 
follow  consisting  of  8  bits  of 
data  and  then  another  GEI  bit  to 
indicate  if  a  further  9  bits 
follow  and  so  on.  Encoders  must 
not  insert  GSPARE  until  specified 
by  CCITT.  Decoders  must  be 
designed  to  discard  GSPARE  if  GEI 
is  set  to  1.  This  will  allow 
CCITT  to  specify  future 
"backward"  compatible  additions 
in  GSPARE. 

Note:  Emulation  of  start  codes 
may  occur  if  the  future 
specification  of  GSPARE  has  no 
restrictions  on  the  final  GSPARE 
data  bits. 

8.2.3  Macroblock  Layer.  Each 
GOB  is  divided  into  33 

,  MBA  '  myPB  '  MQUAf^  '  MVD  '  CBP  '  Block  Data  , 

'  I  I  I  I  I  ' 


Figure  9 

Structure  of  Macroblock  layer 

Macroblock  Address  (MBA)  Stuffing) .  This  codeword  should 

Variable  length  be  discarded  by  decoders. 

The  VLC  for  start  code  is  also 
shown  in  Table  1. 

MBA  is  always  included  in 
transmitted  macroblocks. 

Macroblocks  are  not  transmitted 
when  they  contain  no  information 
for  that  part  of  the  picture. 


An  extra  codeword  is  available  in 
the  table  for  bit  stuffing 
immediately  after  a  GOB  header  or 
a  coded  macroblock  (MBA 


A  variable  length  codeword 
indicats  the  position  of  a 
macroblock  within  a  group  of 
blocks.  The  transmission  order 
is  shown  in  Figure  8.  For  the 
first  transmitted  macroblock  in  a 
GOB,  MBA  is  the  absolute  address 
in  Figure  8.  For  subsequent 
macroblocks,  MBA  is  the 
difference  between  the  absolute 
addresses  of  the  macroblock  and 
the  last  transmitted  macroblock. 
The  code  table  for  MBA  is  given 
in  Table  1. 


n  *”2  *”3  ^4  ^5^6  ? 

^124344^1  8^1 9^2q,_21^2^ 

l23|24i25L2^27128j29j30j31i.3^33J 

Figure  8 

Arrangement  of  Macroblocka 
In  GOB 

Data  for  a  macroblock  consists  of 
a  MB  Header  followed  by  data  for 
blocks  (Figure  9) .  MQUANT,  MVD 
and  CBP  are  present  when 
indicated  by  MTYPE. 


A  bit  which  when  set  to  ' 1 ' 
signals  the  presence  of  the 
following  optional  data  field. 

Spare  Information  (GSPARE) : 
0/8/16. . .  bits 
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Tabl*  1 

VXtC  Tabltt  for  Macroblock  Addraaalng 


MBA 

CODE 

MBA 

CODE 

1 

1 

17 

0000 

0101 

10 

2 

Oil 

18 

0000 

0101 

01 

3 

010 

19 

0000 

0101 

00 

4 

0011 

20 

0000 

0100 

11 

5 

0010 

21 

0000 

0100 

10 

6 

0001  1 

22 

0000 

0100 

oil 

7 

0001  0 

23 

0000 

0100 

010 

8 

0000  111 

24 

0000 

0100 

001 

9 

0000  110 

25 

0000 

0100 

000 

10 

0000  1011 

26 

0000 

0011 

111 

11 

0000  1010 

27 

0000 

0011 

110 

12 

0000  1001 

28 

0000 

0011 

101 

13 

0000  1000 

29 

0000 

0011 

100 

14 

0000  0111 

30 

0000 

0011 

oil 

15 

0000  0110 

31 

0000 

0011 

010 

16 

0000  0101  11 

32 

0000 

0011 

001 

33 

0000 

0011 

000 

MBA  Stuffing 

0000 

0001 

111 

Start  code 

0000 

0000 

0000  0001 

Type  Information  (MTYPE) : 
Variable  Length 


included  elements  and  VLC  words 
are  listed  in  Table  2. 


Variable  length  codewords  give  MTYPE  is  always  included  in 

information  about  the  macroblock  transmitted  macroblocks . 

and  which  data  elements  are 
present.  Macroblock  types, 

Table  2 

VLC  table  for  MTYPB 


Prediction 


MQUANT  MVD  CBP  TCOEFF  VLC 


Intra 

Intra 


Inter 

Inter 

Inter 

+ 

MC 

Inter 

+ 

MC 

Inter 

+ 

MC 

Inter 

+ 

MC 

+ 

FIL 

Inter 

+ 

MC 

+ 

FIL 

Inter 

+ 

MC 

+ 

FIL 

X 

X 


X 


X 


X 

0001 

X 

0000 

001 

X 

X 

1 

X 

X 

0000 

1 

X 

0000 

0000  1 

X 

X 

X 

0000 

0001 

X 

X 

X 

0000 

0000  01 

X 

001 

X 

X 

X 

01 

X 

X 

X 

0000 

01 

Note  1:  'x'  means  that  the  item  is  present  in  the  macroblock 
Note  2;  It  is  possible  to  apply  the  filter  in  a  non-motion  compensated 
macroblock  by  declaring  it  as  MC  +  FIL  but  with  a  zero  vector. 


Quantizer  (MQUANT) :  5  bits 
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MQUANT  is  present  only  if  so 
indicated  by  MTYPE. 

A  codeword  of  5  bits  signifies 
the  quantizer  to  be  used  for  this 
and  any  following  blocles  in  the 
group  of  blocks  until  overridden 
by  any  subsequent  MQUANT. 

Codewords  for  MQUANT  are  the  same 
as  for  GQUANT. 

Motion  Vector  Data  (MVD) : 

Var:iable  length 

Motion  Vector  Data  is  included 
for  all  MC  macroblocks.  MVD  is 
obtained  from  the  macroblock 
vector  by  subtracting  the  vector 
of  the  preceding  macroblock.  For 
this  calculation  the  vector  of 
the  preceding  macroblock  is 
regarded  as  zero  in  the  following 
three  situations: 

1)  Evaluating  MVD  for  macroblocks 

I,  12  and  23. 

2)  Evaluating  MVD  for  macroblocks 

in  which  MBA  does  not 
represent  a  difference  of 
1. 

3)  MTYPE  of  the  previous 

macroblock  was  not  MC. 

MVD  consists  of  a  variable  length 
codeword  for  the  horizontal 
component  followed  by  a  variable 
length  codeword  for  the  vertical 
component.  Variable  length  codes 
are  given  in  Table  3. 

Advantage  is  taken  of  the  fact 
that  the  range  of  motion  vector 
values  is  constrained.  Each  VLC 
word  represents  a  pair  of 
difference  values.  Only  one  of 
the  pair  will  yield  a  macroblock 
vector  falling  within  the 
permitted  range. 

Coded  Block  Pattern  (CBP)  : 
Variable  length 


coefficient  is  transmitted.  The 
pattern  number  is  given  by 

32»Pi  *  16*P2  8*P3  t'P^  -  2*P5  ♦  pg 

where  Pn  is  1  if  any  coefficient 
is  present  for  block  n,  else  0. 
Block  numbering  is  given  in 
Ficpire  10. 

The  codewords  for  CBP  are  given 
in  Table  4 . 

Table  3 


VLC 

table 

for 

MVD 

MVD 

CODE 

-16 

& 

16 

0000 

0011 

001 

-15 

& 

17 

0000 

0011 

oil 

-14 

& 

18 

0000 

0011 

101 

-13 

& 

19 

0000 

0011 

111 

-12 

& 

20 

0000 

0100 

001 

-11 

& 

21 

0000 

0100 

oil 

-10 

& 

22 

0000 

0100 

11 

-9 

& 

23 

0000 

0101 

01 

-8 

6 

24 

0000 

0101 

11 

-7 

i 

25 

0000 

0111 

-6 

& 

26 

0000 

1001 

-5 

& 

27 

0000 

1011 

-4 

& 

28 

0000 

111 

-3 

& 

29 

0001 

1 

-2 

£ 

30 

0011 

-1 

oil 

0 

1 

1 

010 

2 

£ 

-30 

0010 

3 

£ 

-29 

0001 

0 

4 

£ 

-28 

0000 

110 

5 

£ 

-27 

0000 

1010 

6 

£ 

-26 

0000 

1000 

7 

£ 

-25 

0000 

0110 

8 

£ 

-24 

0000 

0101 

10 

9 

£ 

-23 

0000 

0101 

00 

10 

£ 

-22 

0000 

0100 

10 

11 

£ 

-21 

0000 

0100 

010 

12 

£ 

-20 

0000 

0100 

000 

13 

£ 

-19 

0000 

0011 

110 

14 

£ 

-18 

0000 

0011 

100 

15 

£ 

-17 

0000 

0011 

010 

CBP  is  present  if  indicated  by 
MTYPE.  The  codeword  gives  a 
pattern  number  signifying  those 
blocks  in  the  macroblock  for 
which  at  least  one  transform 
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Tabl«  4 


VLC 

table  for 

CBP 

CBP  CODE 

CBP 

CODE 

60 

111 

35 

0001 

1100 

4 

1101 

13 

0001 

1011 

8 

1100 

49 

0001 

1010 

16 

1011 

21 

0001 

1001 

32 

1010 

41 

0001 

1000 

12 

1001 

1 

14 

0001 

0111 

48 

1001 

0 

50 

0001 

0110 

20 

1000 

1 

22 

0001 

0101 

40 

1000 

0 

42 

0001 

0100 

28 

0111 

1 

15 

0001 

0011 

44 

0111 

0 

51 

0001 

0010 

52 

0110 

1 

23 

0001 

0001 

56 

0110 

0 

43 

0001 

0000 

1 

0101 

1 

25 

0000 

1111 

61 

0101 

0 

37 

0000 

1110 

2 

0100 

1 

26 

0000 

1101 

62 

0100 

0 

38 

0000 

1100 

24 

0011 

11 

29 

0000 

1011 

36 

0011 

10 

45 

0000 

1010 

3 

0011 

01 

53 

0000 

1001 

63 

0011 

00 

57 

0000 

1000 

5 

0010 

111 

30 

0000 

0111 

9 

0010 

110 

46 

0000 

0110 

17 

0010 

101 

54 

0000 

0101 

33 

0010 

100 

58 

0000 

0100 

6 

0010 

oil 

31 

0000 

0011 

1 

10 

0010 

010 

47 

0000 

0011 

0 

18 

0010 

001 

55 

0000 

0010 

1 

34 

0010 

000 

59 

0000 

0010 

0 

7 

0001 

1111 

27 

0000 

0001 

1 

11 

0001 

1110 

39 

0000 

0001 

0 

19 

0001 

1101 

8.2.4  Block  Layer .  A 
macroblock  comprises  four 
luminance  blocks  and  one  of  each 
of  the  two  color  difference 
blocks  (Figure  10) . 

qFgi  r-i 

'  5  «  '  6  ' 

LfCJ  I _ J  I _ I 

Y  Cfl  Cr 

Figure  10 

Arrangement  of  Blocks  in  a 
Macroblock 


Data  for  a  block  consists  of 
codewords  for  transform 
coefficients  followed  by  an  end 
of  block  marker  (Figure  11) .  The 
order  of  block  transmission  is  as 
in  Figure  10 . 

[^TCOEFfI  _BQB  j 

Figure  11 

Structure  of  Block  layer 


Transform  Coefficients  (TCOEFF) 

Transform  coefficients  data  is 
always  present  for  all  6  blocks 
in  a  macroblock  when  MTYPE 
indicates  INTRA.  In  other  cases 
MTYPE  and  CBP  signal  which  blocks 
have  coefficient  data  transmitted 
for  them.  The  quantized  transform 
coefficients  are  sequentially 
transmitted  according  to  the 
sequence  given  in  Figure  12. 
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^  1^  2*  6^  9  15^1?  28*  29^ 

L  J.  _l_  L  J  _  L  J  _l_  J 

I  31  51  81  141  171  271  301  431 

'"4‘'l'"l3‘^li'  26'"3?r2'”44’ 

L  1  L  J  I  L  J  -TL  1 

I  lOJ  12l  19l  25»  32l  4ll  45l  54* 

H  -f  —I—  +-  H  --  I—  -f  —  I—  4 

I  11|  20,  24,  33,  40,  46,  53,  55, 

'  21*  23*  34*  39*  47*  52>  56*  61* 

4  _|_  4--l-k-4-l-4 
I  22,  35,  38,  48|  51,  57,  60,  62, 

'  36*  37*  49*  50*  58*  59*  63*  64* 

L  J.  _l_ 

increasing  cycles 
I  per  picture  width 

t 

increasing  cycles 
per  picture  height 


Flgura  12 

Transmission  ordas  for 
transform  coafflciants 


The  most  commonly  occurring 
combinations  of  successive  zeros 
(RUM)  and  the  following  value 
(LEVEL)  are  encoded  with  variable 
length  codes.  Other  combinations 
of  (RUN, LEVEL)  are  encoded  with  a 
20  bit  word  consisting  of  6  bits 
ESCAPE,  6  bits  RUN  and  8  bits 
LEVEL.  For  the  variable  length 
encoding  there  are  two  code 
tables,  one  being  used  for  the 
first  transmitted  LEVEL  in  INTER, 
INTER+MC  and  INTER+MC+FL  blocks, 
the  second  for  all  other  LEVELS 
except  the  first  one  in  INTRA 
blocks  which  is  fixed  length 
coded  with  8  bits . 

Codes  are  given  in  Table  5 . 


Table  5 

VLC  table  For  TCOBFF 


The  most  commonly  occurring  combinations  of  zero-run  and  the  following 
value  are  encoded  with  variable  length  codes  as  listed  in  the  table 
below.  End  of  Block  (EOB)  is  in  this  set.  Because  CBP  indicates  those 
blocks  with  no  coefficient  data,  EOB  cannot  occur  as  the  first 
coefficient.  Hence  EOB  can  be  removed  from  the  VLC  table  for  the  first 
coefficient . 

The  last  bit  's'  denotes  the  sign  of  the  level,  'O'  for  positive 

'1'  for  negative. 


RUN  I  LEVEL I 


CODE 


0 


EOB 


1 


0 

0 

0 

0 


1 

2 

3 

4 


10 

Is  IF  FIRST  COEFFICIENT  IN  BLOCK 
(Note  -  Never  used  in  INTRA  macroblocics) 
lls  NOT  FIRST  COEFFICIENT  IN  BLOCK 
0100  s 
0010  Is 
0000  llOs 
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0 

5 

0010 

0110 

s 

0 

6 

0010 

0001 

3 

0 

7 

0000 

0010 

10s 

0 

8 

0000 

0001 

1101 

s 

0 

9 

0000 

0001 

1000 

3 

0 

10 

0000 

0001 

0011 

s 

0 

11 

0000 

0001 

0000 

s 

0 

12 

0000 

0000 

1101 

Os 

0 

13 

0000 

0000 

1100 

Is 

0 

14 

0000 

0000 

1100 

Os 

0 

15 

0000 

0000 

1011 

Is 

1 

1 

oils 

1 

2 

0001 

10s 

1 

3 

0010 

0101 

s 

1 

4 

0000 

0011 

00s 

1 

5 

0000 

0001 

1011 

s 

1 

6 

0000 

0000 

1011 

Os 

1 

7 

0000 

0000 

1010 

Is 

2 

1 

0101 

s 

2 

2 

0000 

100s 

2 

3 

0000 

0010 

lls 

2 

4 

0000 

0001 

0100  s 

2 

5 

0000 

0000 

1010  Os 

3 

1 

0011 

is 

3 

2 

0010 

0100 

s 

3 

3 

0000 

0001 

1100  s 

3 

4 

0000 

0000 

1001  Is 

4 

1 

0011 

Os 

4 

2 

0000 

0011 

lls 

4 

3 

0000 

0001 

0010  s 

5 

1 

0001 

11s 

5 

2 

0000 

0010 

01s 

5 

3 

0000 

0000 

1001  Os 

6 

1 

0001 

01s 

6 

2 

0000 

0001 

1110  s 

7 

1 

0001 

00s 

7 

2 

0000 

0001 

0101  3 

8 

1 

0000 

Ills 

8 

2 

0000 

0001 

0001  s 

9 

1 

0000 

101s 

9 

2 

0000 

0000 

1000  Is 

10 

1 

0010 

0111 

s 

10 

2 

0000 

0000 

1000  Os 

11 

1 

0010 

0011 

s 

12 

1 

0010 

0010 

s 

13 

1 

0010 

0000 

s 
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14 

1 

0000 

0011 

10s 

15 

1 

0000 

0011 

01s 

16 

1 

0000 

0010 

00s 

17 

1 

0000 

0001 

1111 

s 

18 

1 

0000 

0001 

1010 

3 

19 

1 

0000 

0001 

1001 

s 

20 

1 

0000 

0001 

0111 

s 

21 

1 

0000 

0001 

0110 

3 

22 

1 

0000 

0000 

1111 

Is 

23 

1 

0000 

0000 

1111 

Os 

24 

1 

0000 

0000 

1110 

Is 

25 

1 

0000 

0000 

1110 

Os 

26 

1 

0000 

0000 

1101 

Is 

ESCAPE 

0000 

01 

The  remaining  combinations  of  (RUN,  LEVEL)  are  encoded  with  a  20  bit 
word*  consisting  of  6  bits  ESCAPE,  6  bits  RUN  and  8  bits  LEVEL. 

RUN  is  a  6  bit  fixed  length  code.  LEVEL  is  a  8  bit  fixed  length  code. 


RUN 

CODE 

LEVEL 

CODE 

0 

0000 

00 

-128 

FORBIDDEN 

1 

0000 

01 

-127 

1000  0001 

2 

0000 

10 

• 

• 

63 

1111 

11 

-2 

1111  1110 
1111  1111 

• 

0 

FORBIDDEN 

1 

0000  0001 

2 

0000  0010 

127 

0111  1111 

*Note  -  Use  of  this  20  bit  word  form  for  encoding  the  combinations 
listed  in  the  VLC  table  is  not  prohibited. 

For  all  coefficients  other  than  the  INTRA  DC  one  the  reconstruction 
levels  (REC)  are  in  the  range  -2048  to  2047  and  are  given  by  clipping 
the  results  of  the  following  formulae; 
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REC  -  QUANr  (2*LEVEL+1 ) 
REC  .  QUANr(2*L£VEL-1 ) 
REC  -  QUANr(2*LEVEL+l)-1 
REC  -  QUANr(2*LEVEL-1  )+1 


;LEVEL>0 

;LEVEL<0 


QUANT  =  'odd’ 


;LEVEL>0 

;L£VEL<0 


QUANT 


"even* 


REC.0;LEVEL>0 

Note:  QUANT  ranges  from  1  to  31  and  is  transmitted  by  either  GQUANT  or 
MQUANT. 

Reconstruction  levels  (REC) 


QUANT 


LEVEL 

1 

2 

3 

4 

8 

9 

• 

17 

18 

• 

30 

31 

-127 

-255 

-509 

-765 

-1019 

.  -2039 

-2048 

-2048 

-2048 

-2048 

-2048 

-126 

-253 

-505 

-759 

-1011 

.  -2023 

-2048 

-2048 

-2048 

-2048 

-2048 

-2 

-5 

-9 

-15 

-19 

-39 

-45 

-85 

-89 

-149 

-155 

-1 

-3 

-5 

-9 

-11 

-23 

-27 

-51 

-53 

-89 

-93 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

3 

5 

9 

11 

23 

27 

51 

53 

89 

93 

2 

5 

9 

15 

19 

39 

4S 

85 

89 

149 

155 

3 

7 

13 

21 

27 

55 

63 

119 

125 

209 

217 

4 

9 

17 

27 

35 

71 

81 

153 

161 

269 

279 

5 

11 

21 

33 

43 

87 

99 

187 

197 

329 

341 

56 

113 

225 

339 

451 

903 

1017 

1921 

2033 

2047 

2047 

57 

115 

229 

345 

459 

919 

1035 

1955 

2047 

2047 

2047 

58 

117 

233 

351 

467 

935 

1053 

1989 

2047 

2047 

2047 

59 

119 

237 

357 

475 

951 

1071 

2023 

2047 

2047 

2047 

60 

121 

241 

363 

483 

967 

1089 

2047 

2047 

2047 

2047 

125 

251 

501 

753 

1003 

2007 

2047 

2047 

2047 

2047 

2047 

126 

253 

505 

759 

1011 

2023 

2047 

2047 

2047 

2047 

2047 

127 

255 

509 

765 

1019 

2039 

2047 

• 

2047 

2047 

. 

2047 

2047 

Note;  Reconstruction  levels  are  symmetrical  with  respect  to  the  sign  of 
LEVEL  except  for  2047/-2048. 


For  INTRA  blocks  the  first 
coefficient  is  nominally  the 
transform  DC  value  linearly 
quantized  with  a  stepsize  of  8 
and  no  dead-zone.  The  resulting 
values  are  represented  with  8 
bits.  A  nominally  blac)c  block 
will  give  0001  0000  and  a 
nominally  white  one  1110  1011. 
The  code  0000  0000  is  not  used. 
The  code  1000  0000  is  not  used. 


the  reconstruction  level  of  1024 
being  coded  as  1111  1111  (See 
Table  6) . 


Coefficients  after  the  last  non¬ 
zero  one  are  not  transmitted. 

EOB  (End  of  Block  code)  is  always 
the  last  item  in  blocks  for  which 
coefficients  are  transmitted. 
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Tabltt  6 

Raconstxuctlon  levels  for 
iNTIUl-mode  DC  coefficient 


FLC 

Reconstruction 

level  into  inverse 
transform 

0000 

0001 

(1) 

8 

0000 

0010 

(2) 

16 

0000 

0011 

(3) 

24 

0111 

1111 

(127) 

1016 

1111 

1111 

(255) 

1024 

1000 

0001 

(129) 

1032 

1111 

1101 

(253) 

2024 

1111 

1110 

(254) 

2032 

Note 

:  The 

decoded 

value 

corresponding  to  FLC  'n'  is  8n 
except  FLC  255  gives  1024. 


8 . 3  Multipoint 

Considerations.  The  following 
facilities  are  provided  to 
support  switched  multipoint 
operation. 

8.3.1  Freese  Picture 
Request.  Causes  the  decoder  to 
freeze  its  displayed  picture 
until  a  freeze  picture  release 
signal  is  received  or  a  timeout 
period  of  at  least  6  seconds  has 
expired.  The  transmission  of 
this  signal  is  via  external  means 
(for  example  by  H.221) . 

8.3.2  Fast  Updata  Request . 
Causes  the  encoder  to  encode  its 
next  picture  in  INTRA  mode  with 
coding  parameters  such  as  to 
avoid  buffer  overflow.  The 
transmission  method  for  this 
signal  is  via  external  means  (for 
exeunple  by  H.221)  . 

8.3.3  Freese  Picture 
Release.  A  signal  from  an 
encoder  which  has  responded  to  a 
Fast  Update  Request  and  allows  a 
decoder  to  exit  from  its  freeze 
picture  mode  and  display  decoded 
pictures  in  the  normal  manner. 
This  signal  is  transmitted  by  Bit 
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3  of  PTYPE  (see  8.2.1)  in  the 
Picture  Header  of  the  first 
picture  coded  in  response  to  the 
Fast  Update  Request . 

9.  Transmission  Coder 

9.1  Bit  Rate.  The 

transmission  clock  is  provided 
externally  (for  example  from  an 
1.420  interface) . 

9.2  Video  Data  Buffering. 

The  encoder  must  control  its 
output  bitstreeun  to  comply  with 
the  requirements  of  the 
Hypothetical  Reference  Decoder 
defined  in  section  11. 

When  operating  with  CIF  the 
number  of  bits  created  by  coding 
any  single  picture  must  not 
exceed  256  Kbits.  K-1024. 

When  operating  with  QCIF  the 
number  of  bits  created  by  coding 
any  single  picture  must  not 
exceed  64  Kbits. 

In  both  the  above  cases  the  bit 
count  includes  the  Picture  Start 
Code  and  all  other  data  related 
to  that  picture  including  PSPARE, 
GSPARE  and  MBA  Stuffing.  The  bit 
count  does  not  include  error 
correction  framing  bits,  fill 
indicator  (Fi) ,  fill  bits  or 
error  correction  parity 
information  described  in  9.4 
below . 

Video  data  must  be  provided  on 
every  valid  clock  cycle.  This 
can  be  ensured  by  the  use  of 
either  the  fill  bit  indicator 
(Fi)  and  subsequent  fill  all  I's 
bits  in  the  error  corrector  block 
framing  (See  Figure  13)  or  MBA 
Stuffing  (see  8.2.3). 

9.3  Video  Coding  Delay.  This 
item  is  included  in  this 
recommendation  because  the  video 
encoder  and  video  decoder  delays 
need  to  be  known  to  allow  audio 
compensation  delays  to  be  fixed 
when  video  is  used  to  form  part 
of  a  conversational  service. 
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This  will  allow  lip 
synchronization  to  be  maintained. 
A  method  by  which  the  delay 
figures  are  established  is 
recommended  in  appendix  1.  Other 
delay  measurement  methods  may  be 
used  but  they  must  be  designed  in 
a  way  to  produce  similar  results 
to  the  method  given  in  appendix 
1. 

9 . 4  Forward  Error  Correction 
for  Coded  Video  Signal 

9.4.1  Error  correcting  code . 
The  transmitted  bit-stream  shall 
contain  a  BCH(511»493)  Forward 
Error  Correction  Code.  Use  of 
this  by  the  decoder  is  optional, 
but  will  be  considered  in 
evaluating  the  price-performance 
characteristics  of  competing 
vendor  proposals. 

9.4.2  Generator  Polynomial 

g(x)  »  (x®+x^+l) (x^+x^+x^+x^+1) 

Example:  For  the  input  data  of 
•01111... 11*  (493  bits)  the 
resulting  correction  parity  bits 
are  ' OllOllOlOlOOOllOll'  (18 
bits)  . 


9.4.3  Error  Correction 
Framing.  To  allow  the  video 
data  and  error  correction  parity 
information  to  be  identified  by  a 
decoder  an  error  correction 
framing  pattern  is  included.  This 
consists  of  a  multiframe  of  8 
frames,  each  frcune  comprising  1 
bit  framing,  1  bit  fill  indicator 
(Fi) ,  492  bits  of  coded  data  (or 
fill  all  I's)  and  18  bits  parity. 
The  frame  alignment  pattern  is 

(SiS2S3S4S5S6S7S8)  -  (OOOllOll) 

See  Figure  13  for  the  frame 
arrangement.  The  parity  is 
calculated  against  the  493-bits 
including  Fill  Indicator  (Fi)  . 

The  fill  indicator  (Fi)  can  be 
set  to  zero  by  an  encoder.  In 
this  case  only  492  consecutive 
fill  bits  (fill  all  I's)  plus 
parity  are  sent  and  no  coded  data 
is  transmitted.  This  may  be  used 
to  meet  the  requirement  in  9.2  to 
provide  video  data  on  every  valid 
clock  cycle. 


Transmission  Order 

(q  $2  ^  S4  Ss  Se  S7  Ss  )  =  00011011 


1 

1 

“  - - 

S, 

Data 

Parity 

1 

493 

R 

18 

1 

CODED  DATA 

0 


FILL  (all'V) 


1  492 


Figure  13 
Error  correcting 


frame 
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9.4.4  R«-IiOck  Time  for  Error 
Corrector  Framing.  Three 
consecutive  error  correction 
framing  sequences  (24  bits) 
should  be  received  before  frame 
loc)c  is  deemed  to  have  been 
achieved.  The  decoder  should  be 
designed  such  that  frame  lock 
will  be  reestablished  within 
34000  bits  after  an  error 
corrector  framing  phase  change. 

Note:  This  assumes  that  the  video 
data  does  not  contain  3  correctly 
phased  emulations  of  the  error 
correction  framing  sequence 
during  the  re-locking  period. 


10.  Invara*  Transform 
Accuracy  Specification 

(1)  Generate  random  integer 

pel  data  values  in  the  range  -L 
to  +H  according  to  the  random 
number  generator  given  below  CC 
version) .  Arrange  into  8  by  8 
blocks.  Data  sets  of  10,000 
blocks  should  each  be  generated 
for  (L-256,  H-255) ,  (L=H-5)  and 

(L-H-300) . 

(2)  For  each  8  by  8  block, 
perform  a  separable,  orthonormal, 
matrix  multiply.  Forward  Discrete 
Cosine  Transform  according  to  the 
following  transfer  function  using 
at  least  64-bit  floating  point 
accuracy. 


7  7 

f(u,v)  =  1/4  C(u)  C(v)  Zj  X  F(x,y)  cos[Pi(2x+1)u/16]  cos[Pi(2y+1)v/16] 

x«0  y»0 

with  u,  V,  X,  y  ■  0,  1,  2,  ...,  7 


where : 

x>y  ~  special  coordinates  in  the  pel  domain 
u,v  ■  coordinates  in  the  transform  domain 


C(u)  *  1/SQRT{2)  for  u  -  0, 
C(v)  -  1/SQRT(2)  for  v  -  0, 

(3)  For  each  block,  round  the 
64  resulting  transformed 
coefficients  to  the  nearest 
integer  values.  Then  clip  them 
to  the  range  -2048  to  +2047. 

This  is  the  12 -bit  input  data  to 
the  inverse  transform, 

(4)  For  each  8  by  0  block  of 
12-bit  data  produced  by  step  3, 
perform  a  separable, 
orthonormal,  matrix  multiply. 
Inverse  Discrete  Transform  (lOCT) 
using  at  least  64-bit  floating 
point  accuracy.  Round  the 
resulting  pels  to  the  nearest 
integer  and  clip  to  the  range 
-256  to  +255.  These  blocks  of  8 
by  8  pels  are  the  "reference" 
IDCT  output  data. 


otherwise  1. 
otherwise  1 . 

(5)  For  each  8  by  8  block 
produced  by  step  3,  apply  the 
IDCT  under  test  and  clip  the 
output  to  the  range  -256  to  +255. 
These  blocks  of  8  by  8  pels  are 
the  "test"  IDCT  output  data. 

(6)  For  each  of  the  64  IDCT 
output  pels,  and  for  each  of  the 
10,000  block  data  sets  generated 
above,  measure  the  peak,  mean  and 
mean  square  error  between  the 
"reference"  and  the  "test"  data. 

(7)  For  any  pel,  the  peak 
error  should  not  exceed  1  in 
magnitude.  For  any  pel,  the  mean 
square  error  should  not  exceed 
0.06.  Overall,  the  mean  square 
error  should  exceed  0.02.  For 
any  pel,  the  mean  mean  error 
should  not  exceed  0.015  in 
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magnitude.  Overall,  the  mean 
error  should  not  exceed  0.0015  in 
magnitude . 
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(8)  All  zeros  in  must  produce 
all  zeros  out. 


(9)  Rerun  the  measurements 
using  exactly  the  same  data 
values  of  step  1,  but  change  the 
sign  on  each  pel. 


'C  Program  for  random  number  generation 

/*  L  and  H  must  be  long,  chat  is  32  bits  */ 
long  rand(L,H) 
long  L,  H 

static  long  randx  -  1;  /*  long  is  32  bits  •/ 

static  double  z  -  (double) 0x7 £f££ff£; 

long  i, j; 

double  x;  /*  double  is  64  bits  */ 

randx  -  (randx  *  1103515425)  +  12345; 
i  -  randx  i  0x7f££ff£e;  /*  keep  30  bits  */ 

X  ■  (  (double) i  )  /  z;  /*  range  0  to  0.99999...  */ 

X  *-  (1,+H+l);  /*  range  0  to  <  L+H+1  */ 

j  -  x;  /*  truncate  to  integer  */ 

return (  j  -  L) ;  /*  range  -L  to  H  */ 

) 


11 .  Hypothetical  Reference 
Decoder 

The  Hypothetical  Re£erence 
Decoder  (HBD)  is  de£ined  as 
follows: 

(1)  The  HRD  and  the  encoder 
have  the  same  clock  frequency  as 
well  as  the  same  GIF  rate,  and 
are  operated  synchronously. 

(2)  The  HRD  receiving  buffer 
size  is  (B  256  Kbits)  .  The 
value  of  B  is  defined  as  follows: 

®  “  ^®^max/29.97 

where  Rmax  the  maximum  video 
bit  rate  to  be  used  in  the 
connection. 

(3)  The  HRD  buffer  is 
initially  empty. 

(4)  The  HRD  buffer  is  examined 
at  GIF  intervals  (i33ms) .  If  at 
least  one  complete  coded  picture 
is  in  the  buffer  then  all  the 


data  for  the  earliest  picture  is 
instantaneously  removed  (e.g.  at 
tn+i  in  Figure  14  below) , 
Immediately  after  removing  the 
above  data  the  buffer  occupancy 
must  be  less  than  B.  This  is  a 
requirement  on  the  coder  output 
bitstream  including  coded  picture 
data  and  MBA  stuffing  but  not 
error  correction  framing  bits, 
fill  indicator  (Fi) ,  fill  bits  or 
error  correction  parity 
information  described  in  9.4. 

To  meet  this  requirement  the 
number  of  bits  for  the  (N+l)th 
coded  picture  d^+i  must  satisfy: 

f 

^♦1  2  +  j  R(t)dt  -  B 

where  b^  is  buffer  occupancy  just 
after  the  time  t«j,  t»j  is  the  time 
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2  4 


the  Nth  coded  picture  is  removed  video  bit  rate  at  the  time  t. 

from  the  HRD  buffer,  R(t)  is  the 

HRD  buffer 

occupancy 

(bit) 


Figure  14 

BSD  buffer  oecupeney 


Note:  Time  (tN+j,  -  t^)  is  an  integer  niunber  of  CIF  picture  periods 
(1/29.97,  2/29.97,  3/29,97,  ...). 
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Appendix  1  Codxc  D«lay 
Maasuraaant  Mathod. 

The  video  encoder  and  video 
decoder  delays  will  vary 
depending  on  iir^lementation.  The 
delay  will  also  depend  on  the 
picture  format  (QCIF,  GIF)  and 
data  rate  in  use.  This  section 
specifies  the  method  by  which  the 
delay  figures  are  established  for 
a  particular  design.  To  allow 
correct  audio  delay  compensation 
the  overall  video  delay  needs  to 
be  established  from  a  user 
perception  point  of  view  under 
typical  viewing  conditions. 


B 


Figure  15 
Measuring  points 

Point  A  is  the  video  input  to  the 
video  coder.  Point  B  is  the 
channel  output  from  the  video 
terminal  (i.e.  including  any  FEC, 
channel  framing  etc.)  Point  C  is 
the  video  output  from  the 
decoder . 

A  video  sequence  lasting  more 
than  100  seconds  is  connected  to 
the  video  coder  input  (point  A) 
in  Figure  15  above.  The  video 
sequence  should  have  the 
following  characteristics. 

(1)  It  should  contain  a 
typical  moving  scene  consistent 
with  the  intended  purpose  of  the 
video  codec. 

(2)  It  should  produce  a 
minimum  coded  picture  rate  of  9.5 
Hz  at  the  bit  rate  in  use. 

(3)  It  should  contain  a 
visible  identification  mark  at 
intervals  through  out  the  length 
of  the  sequence.  The  visible 
identification  should  change 
every  97  video  input  frames  and 
be  located  within  the  picture 
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area  represented  by  the  first  GOB 
in  the  picture.  For  ex<ui^le  the 
first  block  in  the  picture  could 
change  from  black  to  white  at 
intervals  of  97  video  frame 
periods.  The  identification  mark 
should  be  chosen  so  that  it  can 
be  detected  at  point  B  and  does 
not  significantly  contribute  to 
the  overall  coding  performance. 

The  codec  and  video  sequence 
should  be  arranged  so  that  the 
bit  stream  contains  less  than  10% 
stuffing  (MBA  stuffing  +  error 
correction  fill  bits) . 

The  encoder  delay  is  obtained  by 
measuring  the  time  from  when  the 
visible  identification  changes  at 
point  A  to  the  time  that  the 
change  is  detected  at  point  B. 
Similarly,  the  decoder  delay  is 
obtained  by  taking  measurements 
at  points  B  and  C. 

Several  measurements  should  be 
made  during  the  sequence  length 
and  the  average  period  obtained. 
Several  tests  should  be  made  to 
ensure  that  a  consistent  average 
figure  can  be  obtained  for  both 
encoder  and  decoder  delay  times. 

Average  results  should  be 
obtained  for  each  combination  of 
picture  format  and  bit  rate 
within  the  capability  of  the 
particular  codec  design. 

Note:  Due  to  pre  and  post 
temporal  processing  it  may  be 
necessary  to  take  a  mid-level  for 
establishing  the  transition  of 
the  identification  mark  at  points 
B  and  C. 
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DRAFT  RECOMMENDATION  AV.231:  MULTIPOINT  CONTROL  UNIT  FOR  AUDIOVISUAL  SYSTEMS 


1.  SCOPE 

2.  FUNCTIONAL  REPRESENTATION 

3.  FUNCTIONAL  UNITS 

3.1  Network  Interface  Unit 

3.2  Demultiplexer 

3.3  Audio  Processor  Unit 

3.4  Video  Processor  Unit 

3.5  Data  Processor  Unit 

3.6  Control  Processor  Unit 

3.7  Multiplexer 

4.  VIDEO  SWITCHING 

5.  SUMMARY  OF  MCU  CAPABILITIES 


1.  SCOPE 

2.  FUNCTIONAL  REPRESENTATION 

A  multipoint  call  may  be  represented  as  in  Figure  1,  wherein  are  shown  a 
number  of  terminals  T,  not  necessarily  identical,  linked  individually  into  a 
network  by  symmetrical  bidirectional  digital  connections,  not  necessarily  all 
of  the  same  capacity.  There  is  no  particular  limit  set  by  the  system  to  the 
number  N  of  terminals  connected  in  the  call,  though  in  practice,  depending  on 
implementation,  the  difficulties  and  cost  will  rise  as  N  increase^  while 
performance  tends  to  fall. 

In  the  representation  of  Figure  1,  the  network  need  only  be  described  by  the 
signal  flows  at  its  ports,  and  their  interdependencies.  The  hardware 
realisation  need  not  be  of  concern:  there  may  be  a  single  MCU  at  one  location: 
alternatively  the  functions  may  be  distributed  to  two  or  more  locations,  but 
in  practical  terms  we  then  refer  to  a  series  of  single  MCUs  linked  together  in 
a  chain.  In  this  Recommendation,  the  text  applies  in  general  to  both 
single-location  and  distributed  MCUs,  and  the  linking  of  MCUs  is  only  treated 
specifically  where  there  is  a  particular  need  to  do  so. 

The  MCU  is  represented  in  more  detail  in  Figure  2. 

Each  port  of  the  MCU  has  a  Network  Interface  Unit,  with  associated  call 
control;  on  the  MCU  side  of  the  Network  Interface  Unit,  the  signal  flows  are 
contained  in  one  or  more  bidirectional  channels  of  equal  capacity,  according 
to  the  transfer  rates  listed  in  Rec  H.221,  Annex  2.  The  incoming  flow  is 
passed  to  the  Demultiplexer,  which  extracts  the  several  types  of  information 
(audio,  video,  data,  and  control)  and  passes  them  to  their  respective 
processors.  The  processors  are  controlled  in  such  a  way  that  an  appropriate 
output  from  each  is  made  available  for  transmission  to  every  terminal:  the 
latter  are  brought  together  in  the  Multiplexer  to  be  combined  into  the 
outgoing  channels. 


The  call-control  units  and  processor  are  outside  the  scope  of  this 
Recommendation  (see  Rec  AV.4©e);  the  other  units  are  described  in  the 
following  sections. 

3.  FUNCTIONAL  UNITS 

3.1  Network  Interface  Unit 


3.2  Demultiplexer 

The  signal  entering  the  demultiplexer  is  that  transmitted  by  a  terminal 
fully  conforming  to  Rec  H.221,  so  the  operation  is  analogous  to  that  of 
the  receiving  side  of  a  terminal,  namely: 

-  recovery  of  frame  and  multiframe  alignment 

-  buffering,  synchronisation  and  ordering  of  multiple  channels  if 
relevant 

-  extraction  of  BAS  codes  and  forwarding  some  of  them  to  the  control 
processor 

-  extraction  of  encryption  vectors  and  decryption  if  relevant 

-  extraction  of  audio  and  forwarding  to  the  audio  processor 

-  extraction  of  video  and  forv?arding  to  the  video  processor 

-  extraction  of  data  and  forwarding  to  the  data  processor 

Correct  timing  relationships  must  be  maintained  between  mode-control  BAS 
and  the  related  audio,  video,  and  data. 

3.3  Audio  Processor  Unit  (APU) 


The  audio  processor  prepares  N  audio  outputs  r.  from  N  audio  inputs  s. ,  by 
switching,  mixing,  or  a  combination  of  these.  '^Mixing  requires  the  ^ 
addition  of  linear  signals  S^  obtained  by  decoding  s.  to  linear  (PCM  or 
analogue),  and  the  recoding  of  the  responses  R.  to  appropriate 
transmission  formats  r  . .  ^ 


An  audio-mixing  MCU  generally  creates  the  responses 

(?  2.  uikcrt.  /ey 

The  value  of<f  must  be  very  small,  as  it  represents  an  echo  to  the 
originating  terminal  the  relative  magnitude  of  this  echo  must  be  less 
than  -45dB(?)  if  there  is  low  bit  rate  moving  video  in  the  call,  and  less 
than  -35dB(?)  otherwise. 


Under  certain  circumstances,  two  terminals  T  and  T  may  be  removed  from 
the  mixing  function  and  interconnected  separately:  ^ 


It  may  be  appropriate  to  limit  the  summation  in  other  ways.  For  example, 
if  N  is  lairge,  the  background  noises  from  all  terminals  may  sum  to  an 
annoying  level:  the  control,  monitoring  the  magnitudes  of  S.,  may  be  set 
to  include  in  the  summation  only  a  limited  number  of  signals  whose  present 
or  recent  past  values  exceed(ed)  a  certain  threshold.  Alternatively,  a 
person  may  control  the  summation  directly  (see  section  3.5.2)  so  that  only 
certain  terminals  may  be  heard. 


If  in  either  of  the  above  cases  the  number  is  limited  to  one,  the  yCU 
becomes  audio-switching  instead  of  audio  mixing.  The  manually  controlled 
audio-switched  approach  is  useful  wnere  encrypted  audio  cannot  be 
de'rypted  at  the  MCU.  The  audio  unit  may  also  contain  a  voice  synthesiser 
or  recorded  message  store,  able  to  be  connected  into  the  mixing  unit  or 
separately  to  any  terminal. 

If  there  is  a  "mixing"  delay  in  the  VPU  (see  below)  greater  than  that  in 
the  APU  by  more  than  30ms,  a  compensating  delay  must  be  added  in  at  the 
appropriate  APU  outputs. 

3.4  Video  Processor  Unit  (VPU) 

The  video  processor  can  operate  in  ways  entirely  analogous  to  those 
described  above  for  the  audio  processor.  "Mixing"  takes  the  form  of 
spatial  multiplexing  into  a  split-screen  format;  to  do  this  the  incoming 
video  signals  may  need  a  certain  amount  of  preprocessing. 

Since  the  video  mixing  function  is  highly  complex,  the  alternative  of 
video  sj^tching  may  be  preferred.  As  for  audio  switching,  the  choice  of 
video  may  be  automatic,  such  that  the  present  speaker  (largest  value  of 
s.)  receives  the  picture  of  the  previous  speaker,  while  all  other 
terminals  receive  the  picture  of  the  present  speaker;  a  time  delay  is 
incorporated  into  the  sjJtJtching  (value  2s)  to  avoid  excessively  frequent 
image  changes,  caused  by  spurious  sounds  such  as  coughing,  knocking  a 
microphone,  and  so  on. 

Again,  the  video  switching  may  be  controlled  directly  by  a  person  making 
his  own  decisions  as  to  which  picture  is  most  appropriate. 

If  there  is  a  codec  delay  in  the  APU  greater  than  that  in  the  VPU  by  more 
than  60ms,  a  compensating  delay  must  be  added  in  at  the  VPU  outputs. 

3 . 5  Data  Processor  (DPU) 

Two  cases  are  distinguished,  according  to  whether  or  not  the  MCU  has 
equipment  for  handling  the  multilayer  protocol  (MLP)  defined  in  Rec 
AV.270. 

3.5.1  Basic  MCU,  Without  MLP  Capability 

In  this  case,  only  on^data  input  can  be  accepted  at  any  one  time,  any 
data  subsequently  arriving  at  another  input  being  ignored.  The  data  is 
broadcast  to  all  other  outputs,  or  at  least  to  those  outputs  determined  by 
the  control  processor.  (M.  C4->v«ctw»u  ait  ot  23  cryecjti'  rcJeiJ 

3.5.2  Enhanced  MCU,  Having  MLP  Capability 

In  this  case  the  data  processor  can  perform  both  the  operation  described 
in  Section  3.5.1,  and  the  MLP  process  described  here.  The  former  is 
applied  to  data  transmitted  with  MLP  "off",  and  to  OLSD  (see  Rec  H.242) 
where  MLP  is  "on" . 

The  data  contained  within  the  MLP  is  passed  to  the  MLP  Processor,  which 
performs  one  or  more  of  the  following  functions  (see  Rees  AV.270  ff); 


-  processing  of  telematic  information 


-  processing  of  conference  control  signals  ' request/ grant  floor, 
chairman  token  control,  audio/video  switching). 

3 . o  Control  Processor  Unit  ^CPU) 

The  control  processor  is  responsible  for  determining  the  correct  routeir.g, 
mixing/switching,  format  and  timing  of  the  audio,  video,  data  and  control 
signals  passed  to  each  multiplexer  for  outward  transmission. 

3.6.1  Incoming  BAS  Commands 

The  CPU  ensures  that  the  correct  audio  decoding  algorithm  is  used  on  each 
input  to  the  audio  mixer;  that  data  is  sent  to  the  broadcast  unit  or  ML? 
Processor  as  appropriate. 

3.6.2  Outgoing  BAS  Commands 

The  CPU  ensures  that  the  correct  audio  encoding  algorithm  is  used  on  each 
output  from  the  audio  mixer,  and  that  the  desired  switching  or  summation 
has  been  performed  in  each  case;  that  the  desired  switching  for  mixing  of 
video  signals)  has  been  made  to  each  output  of  the  VPU.  It  transmits  VCF 
(see  Rec  H.230)  to  all  relevant  terminals  at  a  set  time  before  switching 
the  video  sent  to  them,  and  VCU  to  a  terminal  whose  video  is  about  to  be 
sent  to  another  terminal;  the  procedure  for  this  is  ser  out  in  section  d. 

The  CPU  switches  mode  on  outgoing  streams  to  accommodate  the  appropriate 
combination  of  audio,  video,  and  data,  according  to  the  declared 
capabilities  of  the  connected  terminals  (see  Rec  AV.2d3). 

3.6.3  Incoming  BAS  Capabilities 

The  capability  codes  from  all  N  terminals  are  stored;  whenever  a  new  set 
IS  sent  by  a  terminal,  it  replaces  completely  the  previous  set  (exception: 
encryption  capability), 

3.6.4  Outgoing  BAS  Capabilities 

The  values  to  be  sent  at  each  of  the  N  ports  are  determined  according  to 
Rec.  AV.243. 

3.7  Multiplexer 

The  multiplexer  sets  up  a  frame  structure  on  the  outgoing  channeKs) 
according  to  Rec  H.221,  and  loads  into  this  the  BAS  values  from  the  CPU 
and  the  outputs  of  the  APU,  VPU  and  DPU. 

4.  VIDEO  SWITCHING 

When  it  is  decided  within  the  CPU  that  terminal  A,  currently  receiving  the 
video  signal  from  terminal  B,  should  instead  be  sent  that  from  terminal  C,  the 
following  procedure  is  used  (codes  VCF,  VCU  are  specified  in  Rec  H.230). 

(a)  The  MCU  transmits  VCF  to  terminal  A,  and  immediately  afterwards  switches 
video  such  that  the  picture  from  C  is  transmitted  towards  A. 


(b)  Terminal  A  receives  VCF,  and  freezes  its  currently  displayed  picture;  it 
ignores  subsequent  decoded  video  information,  but  continues  to  track  tr.e 
error-correction  framing,  and  to  monitor  Picture  Headers  for  tbe  ricT'ure 
Freeze  Release  command. 

'c'  Vhen  incoming  video  to  A  changes  from  B-picture  to  C-picture, 
error-correction  frame  alignment  is  lost,  and  will  take  a  time  T  to  recover, 
dependent  on  the  video  bit  rate  and  other  factors. 

(d)  After  a  time  greater  than  T,  the  MCU  transmits  VCU  to  terminal  C. 

'e)  On  receipt  of  VCU,  terminal  C  sends  its  next  video  frame  in  "fast-update" 
mode  ( Rec  H.261,  Section  4.3.2),  together  with  the  Picture  Freeze  Release 
command. 

(f)  On  receipt  of  the  Picture  Freeze  Release  command,  terminal  A  reverts  to 
displaying  the  incoming  decoded  picture. 

Note :  users  at  other  terminals  which  have  been  receiving  picture  C 
continuously  during  the  above  procedure  will  nevertheless  be  aware  of  the 
switching  action  because  of  the  use  of  the  fast-update  mode:  this  is  the 
transmission  of  a  single  new  picture  over  a  period  inversely  proportional  to 
video  bit  rate  -  at  320  kbit/s  this  period  is  likely  to  be  about  0.5  seconds. 

5.  SUMMARY  OF  MCU  CAPABILITIES 

The  MCU  capabilities  must  be  such  as  to  handle  the  signals  of  the  terminals 
with  which  it  is  to  be  used,  as  listed  and  defined  in  Rec  H.242. 

Note:  this  section  is  concerned  with  the  internal  capabilities  of  the  MCU;  tr.e 
3AS-capabilities  declared  at  any  time  on  a  particular  port  of  an  MCU  are  a 
combinatorial  function  of  the  terminals  connected  -  see  Rec  AV.243. 

(a)  Audio :  an  audio-mixing  MCU  must  possess  decoding  and  encoding  capabilities 
from  the  set  A-0,  A-1,  A-2,  A-3.  An  audio-switching  MCU  does  not  decode  any 
audio  signals;  internally  generated  messages  may  be  transmitted  as  PCM. 

(b)  Video:  an  MCU  may  or  may  not  be  able  to  handle  video.  If  it  does  so  by 
switching,  the  different  video  capabilities  defined  in  Pec  H.242  are  of  no 
concern;  however  a  video-mixing  MCU  would  have  to  take  them  into  account. 

(c)  Trauisfer  Rate:  the  same  values  as  defined  in  Rec  H.242. 

(d)  Restricted-Network  Capability:  for  further  study. 

(e)  Data  (except  MLP):  since  the  only  function  of  the  MCU  is  broadcasting  of 
data  streams,  it  may  be  presumed  that,  possessing  this  capability  at  all,  it 
is  available  at  rates  up  to  the  highest  transfer  rate. 

(f)  MLP:  the  MCU  requires  a  considerable  body  of  software  to  handle  MLP; 
however,  while  there  might  well  be  speed  limitations  arising  from  computing 
power,  it  would  be  unwise  to  impose  a  physical  limit  lower  than  the  highest 
transfer  rate. 

(g)  Encryption:  for  further  study. 

(h)  VLE  Capability:  the  MCU  may  or  may  not  be  able  to  handle  variable  length 
extension  BAS  codes. 


Examples 

fi)  A  basic  ISDN  MCU  might  well  possess  the  following  capab 
-  A-3,  switched  video,  T-13  •<-  T-2B,  Data  fbroadcas 

(ii)  An  audiographic  MCU  might  be: 

/A-2,  T-13,  Data.  MLP,  VLE7 

(iii)  A  videoconference  MCU  might  be: 

ZA-2,  switched  video,  T-2B  +  T-HO,  Data,/ 
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1.  INTRODUCTION  AND  SCOPE 

In  a  point-to-point  connection  between  two  terminals,  it  is  worthwhile  to  get 
the  best  quality  working  mode,  according  to  the  respective  capabilities  of  the 
terminals;  if  the  two  terminals  are  quite  different,  it  is  obvious  that  the 
working  mode  is  limited  by  the  lower  capability  terminal. 

In  a  multipoint  connection,  it  must  be  assumed  that  different  terminals  can  be 
connected  to  the  same  multipoint  control  unit  (MCU),  in  which  case  it  may  not 
be  appropriate  that  the  working  mode  be  the  loweat  common  one.  For  example, 
if  three  videophones  and  one  digital  telephone  are  connected  together  via  arv 
MCU,  it  would  not  be  very  sensible  that  all  terminals  work  in  an  audio  mode 
only.  The  objective  of  this  paper  is  to  describe  a  MCU  rule  to  avoid  such  a 
situation. 

Recommendation  AV.242  provides  for  communication  between  two  audiovisual 
terminals  connected  point-to-point,  using  the  frame  structure  defined  in  Rec 
H.221  and  the  control  and  indication  symbols  defined  in  AV.230. 

Three  or  more  audiovisual  terminals  may  be  put  into  communication  to  form  a 
conference  call,  by  means  of  one  or  more  multipoint  control  units  (MCU).  The 
means  by  which  digital  channels  are  established  between  terminals  and  MCUs, 
and  between  MCUs,  is  outside  the  scope  of  this  recommendation,  although 
reference  is  made  to  relevant  circumstances  in  section  3.  This  recommendation 
concerns  only  the  flows  of  signals  along  the  fixed  digital  paths,  which  may  be 
at  64  kbit/s  or  multiples  thereof  up  to  2048  kbit/s.  The  flow  c'^nsists  of  a 


multiplex  of  audio,  video,  telematic,  user  data,  and  control  and  indication 
signals,  which  must  be  handled  by  the  MCU  in  a  way  which  is  satisfaccory  tc 
the  users . 

The  signal  multiplex  on  each  path  is  fully  in  accordance  .vicn  H.221:  the  3A3 
commands  define  explicitly  how  the  demultiplexer  at  the  end  of  each  link  shall 
operate.  Likewise  the  basic  procedures  for  initialisation  and  mode  switching 
are  fully  in  accordance  with  those  defined  in  AV.242  for  point-to-point 
working.  However  the  composition  of  the  multiplexed  signal  transmitted  by 
each  terminal  and  by  the  MCU  is  determined  by  terminal  procedures  and  MCU 
procedures ,  as  follows; 

(a)  terminal  procedures  are  defined  in  service-specific  system 
recommendations,  such  as  AV.320  for  visual  telephony: 

(b)  MCU  procedures  are  defined  in  this  recommendation,  and  are  not  cf 
themselves  service-specific; 

(c)  multi-layer  protocol  (MLP):  by  making  use  of  the  MLP  defined  in  the 
AV.270  series,  MCU  and  terminal  procedures  may  be  greatly  enhanced, 
offering  far  more  sophisticated  specific  applications  to  the  user. 

2.  DEFINITIONS 

Multipoint  Control  Unit  (MCU): 

Convenor  Terminal;  a  terminal  possessing  a  token  conveying  a  certain  measure 
of  authority  over  the  operation  of  the  MCU;  the  token  may  be  assigned  by 
prearrangement,  by  an  operator,  or  by  protocol  during  the  call. 

Convenor  Port:  that  port  of  the  MCU  to  which  the  convenor  terminal  is 
connected. 

Primary  and  Secondeu'y  Ports:  while  all  ports  of  an  MCU  may  be  physically  the 
same,  distinctions  may  be  made  by  the  internal  software,  on  the  basis  of 
declared  terminal  capabilities,  such  that  the  ports  are  not  all  treated  on  an 
equal  basis.  In  general,  a  multipoint  call  will  involve  two  or  more  terminals 
intercommunicating  on  an  equal  basis,  at  their  highest  common  capability:  the 
MCU  would  designate  as  "primary"  those  ports  to  which  these  terminals  are 
connected,  and  for  simplicity  these  terminals  can  be  referred  to  as  "primary 
terminals"  for  the  purposes  of  this  one  call.  The  selection  of  an  appropriate 
common  level  for  primary  communication  is  specified  in  section  6. 

One  or  more  additional  terminals  may  take  part  in  the  multipoint  call,  even 
though  they  do  not  have  sufficient  capability  to  communicate  on  an  equal  basis 
with  primary  terminals;  these  may  be  designated  "secondary  terminals", 
communicating  with  the  others  only  by  such  compatible  signals  as  can  be  made 
available  (eg,  speech  only),  the  MCU  having  designated  the  appropriate  port 
accordingly.  Note  that  if  this  provision  were  not  made,  then  the  addition  of 
a  telephony  terminal  to  a  videophone  conference  would  cause  all  picture 
transmission  to  be  discontinued. 

The  concept  of  primary/secondary  terminals  is  introduced  in  this 
Recommendation  for  clarity  in  the  description  of  procedures.  A  more 
generalised  MCU  may  be  devised  in  which  a  rigid  distinction  between  primary 
and  secondary  ports  is  not  necessary:  this  matter  is  discussed  further  in 
Appendix  1. 


3,  MULTIPOINT  CONFIGURATIONS 


Star:  all  terminals  connected  to  a  single  MCU;  all  primarv  Terminals  are 
connected  at  the  same  effective  bit  rate,  being  64  kbit/s  or  a  multiple  up  to 
2048  kbit/s  (rates  defined  in  Annex  2  to  Recommendation  H.221);  secondary 
terminals  may  be  connected  at  a  lower  rate. 

Dumb-bell;  terminals  are  connected  to  one  of  two  MCUs,  which  are  themselves 
interconnected  at  the  same  effective  rate  as  the  primary  terminals. 

MCU  Chain:  three  or  more  MCUs  may  be  connected  in  tandem  (but  not  in  a  ring) 
with  terminals  connected  to  each,  the  MCUs  being  interconnected  at  the  same 
effective  rate  as  primary  terminals. 

Call  Set-up  Configurations:  arrangements  for  setting  op  multipoint  call  are 
described  in  Recommendation  AV.440. 

4.  MULTIPOINT  CONTROL  UNIT  CAPABILITIES  AND  REQUIREMENTS 
4.1  MCU  Capabilities 


Communication  between  each  terminal  and  an  MCU  is  on  the  same  basis  as 
between  two  terminals  in  a  point-to-point  call,  and  governed  by  procedures 
similar  to  those  in  Rec  H.242.  For  this  purpose  the  MCU  transmits  a  set 
of  capabilities,  known  as  "MCU  capabilities",  to  ensure  that  each  terminal 
does  not  transmit  signal  which  cannot  be  decoded  at  the  MCU  or  passed  on 
other  connected  terminals.  It  is  to  be  noted  that  the  capabilities  are 
not  necessarily  those  of  the  MCU  itself  (ie,  possibly  related  to  other 
terminals)  and  not  necessarily  the  same  at  each  port  (ie,  the  terminals 
may  be  treated  differently),  and  furthermore  will  vary  during  the  call 
(see  Sections  6-9). 

Audio  Capability 

Since  audio  is  usually  mixed  at  the  MCU  (see  Rec  AV.231),  the  capability 
is  set  at  the  common  mode  to  be  enforced;  secondary  terminals  may  be  added 
in  without  reaching  the  common  "primary"  audio  mode. 

Transfer-rate  Capability 

This  is  set  to  the  highest  common  value  for  primary  terminals,  unless  the 
MCU  itself  has  a  lower  capability  determined  by  its  access  ports. 

Video  Capability 

This  is  set  to  the  highest  common  value  for  primary  terminals;  towards 
secondary  terminals  it  may  be  advisable  to  declare  no  video-capability,  if 
it  is  thought  desirable  to  avoid  the  circumstance  in  which  images  from  the 
secondary  can  be  seen  by  primaries,  but  the  secondary  terminal  cannot  see 
primary  images  because  its  receiving  capability  is  too  low. 

Restricted  Network  Capability 

This  is  set  if  the  primary  communication  is  chosen  to  be  in  modes  of  the 
restricted  type  (see  Rec  H.221,  Annex  9). 


Other  Capabilities  (see  Rec  H.242,  Capability  Table  Z) 

These  are  set  towards  primary  terminals  if  common  to  primary  terminals; 
towards  secondaries  they  may  be  set  if  the  configuration  of  the  MCT  13 
such  that  it  can  cope  (for  example,  ML?  up  to  6.4  kbit/s  may  be  possible 
to  ail  terminals). 

4.2  MCU  Requirements 

The  requirements  of  MCUs  are  defined  in  Rec  AV.231;  a  few  points  are 
reproduced  below. 

Basic  MCU:  such  an  MCU  has  no  MLP  capability,  and  no  special  video/data 
storage/conversion  facilities.  Secondary  terminals  are  connected  by  audio 
only  (for  further  study). 

Enhanced  MCU:  optional  enhancements  include  MLP  capability,  and/or  the 
means  for  conversion  of  signals. 

All  MCUs  must  conform  to  revisions  of  Rees  H.221  and  AV.242  and  this 
Recommendation . 

Treatment  of  Signals: 

I  -  audio  signals  are  generally  mixed  in  such  a  way  that  every  terminal  is 
sent  a  linear  addition  of  the  audio  signals  from  all  other  terminals; 

-  moving  video  of  participants,  automatic  switching  based  on  speech  power 
evaluation,  present  speaker  image  distributed  to  all  others;  previous 
speaker  image  sent  to  present  speaker  (alternative  transmissions  under 
user  control  are  invoked  by  means  of  an  MLP  or  by  means  of  the  MCU 
control ) ; 

-  data,  broadcast  from  one  terminal  to  all  others  (alternative 
transmissions  under  user  control  2ure  invoked  by  means  of  an  MLP). 

5.  TERMINAL  REQUIREMENTS  AND  OPTIONS 

All  terminals  must  conform  to  the  provisions  of  Rees  H.221,  H.230  and  H.242. 

Optional  Convenor  Functions:,  request/release  of  convenor  token,  using  MCR, 

MCT;  call  control  capability  (see  Rec  AV.llO). 

6.  BASIC  MCU:  INITIALISATION  PROCEDURES 

Some  terminals  may  be  able  to  recognise  whether  they  are  connected  to  another 
terminal  or  to  a  MCU,  but  this  is  not  the  general  situation.  It  is  therefore 
necessary  to  adopt  a  similar  procedure  for  point-to-point  and  MCU  connections. 

At  the  beginning  of  the  call,  the  terminal  sends  its  capabilities  and  is 
waiting  t^  receive  frame  structure  and  capabilities,  as  described  in  H.242, 
with  transmission  in  a  mode  OF  only.  Therefore,  the  MCU  must  send  appropriate 
capabilities,  according  to  the  phase  of  the  multiple  call  set-up:  at  the 
completion  of  call  set-up  on  each  port,  the  MCU  begins  transmitting  in  mode  OF 
with  capabilities  as  indicated  below. 


6 . 1  First  Cat^l  Connected  to  MCU 

The  MCU  registers  the  capability  of  this  first  terT.ir.al,  which  it 
designates  Tl.  If  T1  declares  MLP-cap,  and  if  also  -he  MCU  has  ML? 
candling  equipment,  MLP-cap  is  transmitted  in  both  directions  and  the  ML? 
channel  is  opened  by  the  MCU,  permitting  greatly  enhanced  communication 
possibilities  (such  as  vetting  of  subsequent  terminals  by  Tl  before  their 
addition  to  the  audio  mixer,  etc). 

If  Tl  does  not  declare  MLP-cap,  the  MCU  transmits  only  PCM-audio 
capability  in  mode  OF,  with  the  synthesised  message  Ml  (see  Rec  AV.d^c, 
section  N)  and  the  C&I  symbol  MIZ  (see  Rec  H.230)  indicating  that  no  other 
terminals  are  yet  connected. 

Optionally,  if  there  is  mutual  video  capability  this  could  also  be  invoked 
(for  further  study). 

6.2  Second  C»I1  Connected  to  MCU 

The  MCU  registers  the  capability  of  the  second  terminal  upon  recovering 
frame  alignment,  while  transmitting  those  capabilities  of  Tl  that  it  can 
itself  handle  (this  may,  for  example,  exclude  MLP  or  video).  Terminals  Tl 
and  T2  my  then  switch  to  other  suitable  modes,  according  to  their  own 
procedures . 

6 . 3  Third  Call  Connected 

MCU  registers  the  capability  of  terminal  T3;  using  criteria  given  in 
section  6.4  below,  the  MCU  determines  whether  T3  is  to  be  treated  as 
primary  or  secondary:  if  T3  is  to  be  primary,  a  further  check  is  made  to 
determine  whether  T2  should  be  dropped  to  secondairy  status.  The  MCU  then 
transmits  on  all  its  ports  capability  equivalent  to  the  common  capability 
of  the  primary  terminals.  It  also  transmits  to  any  secondary  terminal  the 
C&I  symbol  MIS,  indicating  the  secondary  status  accorded;  if  possible,  the 
terminal  should  display  its  secondaury  status  to  its  user,  though  this  may 
become  apparent  from  verbal  communication  also. 

6.4  Selection  of  Primary  Capability 

The  primary  capability  may  be  fixed  or  variable,  according  to  the  chosen 
one  of  several  approaches,  as  follows: 

(a)  specified  by  the  service  provider  or  manufacturer,  and  fixed  in  the 
MCU; 

(b)  set  by  the  convenor  terminal  using  MLP  commyiMr6ation; 

(c)  set  Iby  the  MCU  at  the  capability  of  the  convenor  terminal; 

(d)  set  by  the  MCU,  initially  at  the  capability  of  the  convenor  terminal 
but  subsequently  lowered  to  match  communication  as  much  as  possible. 

The  algorithm  for  method  (d)  is  set  by  the  manufacturer,  taking  into 
account  the  following  principles  if  relevant. 

(i)  If  audio  is  mixed  (rather  than  only  switched)  in  the  MCU  then  since 
the  mixing  must  be  linear  no  restraint  is  placed  on  the  speech  bandwidth 
or  coding  algorithm  on  any  path:  if  two  or  more  terminals  are  capable  of 


'vid0band  audio  (in  addition  to  video  if  relevant)  they  may  use  this 
independently  of  whether  they  are  designated  primary  or  secondary. 

However  if  the  selection  of  wideband  audio  between  two  or  more  tsrmina-s, 
together  with  video,  would  have  the  result  that  another  terminal  .eg,  13 
/ideophone)  could  not  receive  video,  then  it  may  be  advisable  to  exclude 
wideband  audio  from  the  primary  set. 

lii)  If  the  convenor  and  at  least  one  other  terminal  have  video 
capability,  then  all  terminals  without  video  should  probably  be  designated 
secondary . • 

When  referring  to  a  "higher"  or  "lower"  capability  with  respect  to  audio 
with  video  only,  the  hierarchy  is  taken  to  be  that  of  Table  1/H.320, 
together  with  the  principle  that  all  GIF  modes  are  higher  than  QCIF, 
regardless  of  associated  minimum  picture  interval  capability.  It  must 
not,  however,  be  inferred  that  a  terminal  capability  includes  all  lower 
values:  for  example,  CIF/7.5  does  not  necessarily  include  OCIF/30,  and  A-3 
does  not  necessarily  include  A-2. 

'  2  i/tcuu  Zha  firu  hrr  tu,v  /Vli.  -^.i  .•  .my*  ^_7>i 

6 . 5  Fourth  Call  Connected 

The  procedure  followed  is  essentially  that  of  section  6.3  above, 
establishing  whether  the  newcomer  is  to  be  accorded  primary  or  secondary 
status,  and  checking  whether  any  existing  primary  terminals  should  be 
dropped  to  secondary. 

6.6  Extension  to  Multiples  of  64  kbit/s 

If  the  convenor  and  the  terminals  selected  as  primary,  according  to  the 
process  of  section  6.4  above,  have  the  capability  to  cope  with  at  least  m 
additional  channels,  then  the  transmitted  MCU  transfer-rate  capability 
reflects  the  (m  +  1)  rate  to  relevant  terminals,  and  the  additional 
channels  are  set  up  according  to  the  terminal  procedures. 

The  MCU  transmits  the  symbol  MCS,  to  ensure  that  it  retains  control  of  the 
moment  when  expansion  of  audiovisual  signals  to  higher  rates  can  be 
released.  When  all  the  requested  additional  channels  are  available,  or 
after  expiry  of  a  timer  {5m  seconds?),  MCN  is  transmitted,  enabling 
primary  terminals  to  make  use  of  the  additional  capacity. 

Note;  the  procedure  may  not  be  necessary  for  two-B  calls;  it  may  be 
sufficient  for  the  MCU  to  allow  expansion  to  two-B  as  soon  as  the  convenor 
and  one  other  terminal  have  two  B  channels  connected,  temporarily  dropping 
to  secondary  status  any  other  terminals  which  have  not  yet  completed  the 
second  B-channel  connection. 

7.  BASIC  MCU:  MODE  SWITCHING  FOR  DATA  DISTRIBUTION  IN  SIMPLE  MULTIPOINT 
CONFERENCES 

In  a  point-to-point  connection,  a  terminal  may  transmit  data  to  the  other  end 
(having  received  a  data  capability  BAS)  simply  by  mode  switching  and  putting 
the  data  into  the  appropriate  position  in  the  multiplex. 

In  a  multipoint  call  involving  video  this  will  not  generally  be  possible, 
because  not  only  must  the  outgoing  video  rate  be  dropped  but  also  that  of 
video  signals  emanating  from  other  terminals. 


The  terminal  Tj^  wishing  to  send  data  opens  the  appropriate  data  channel  jsir.g 
the  =AS  data  command,  but  puts  no  data  into  it.  (The  terminal  is  aware  cf  tr.e 
multipoint  configuration,  having  received  MIC  from  the  MCI'. 

Detecting  the  BAS  command  change,  the  MCU  transmits  MCS  to  ail  terminals  ctner 
than  the  data  originator,  enforcing  symmetrical  transmission,  thereby  leaving 
the  desired  capacity  available.  The  MCU  sends  the  new  data  command  to  all 
terminals.  When  T^^  detects  incoming  data  command  change,  it  is  free  to 
transmit  the  data.  The  MCU  invokes  the  data-broadcast  function  from  the  time 
all  its  incoming  videostreams  have  been  lowered  in  bit  rate.  When  T  ends 
transmission  of  data,  it  closes  the  appropriate  data  channel  using  tRe  BAS 
data  command,  the  MCU  then  transmits  MCN  to  all  other  terminals. 

3.  ENHANCED  MCU  WITH  MLP :  INITIALISATION  PROCEDURE 

The  procedure  essentially  follows  that  of  section  6,  the  capability  BAS  being 
included  in  the  capability  exchanges.  When  the  MCU  has  detected  that  ont  or 
more  terminals  have  MLP  capability,  the  6.4  kbit/s  data  channel  is  opened  to 
ail  terminals,  and  by  transmitting  the  symbol  MCS  it  is  ensured  that  the  same 
capacity  is  also  vacated  on  the  incoming  direction  to  the  MCU.  It  is 
necessary  to  do  this  to  all  terminals,  to  ensure  that  those  not  having  ML? 
capability  do  not,  for  example,  transmit  too  great  a  video  data  rate.  MLP 
exchanges  may  now  take  place  between  those  terminals  having  this  capability 
I  and  the  MCU,  the  space  capacity  to  other  terminals  being  left  empty. 

9.  BASIC  MCU:  SUSPENSION  PROCEDURE 

10.  ENCRYPTION 

11.  PROCEDURES  RELATED  TO  MAINTENANCE 

12.  SEQUENCING  OF  BAS  CODES 

The  principles  of  Rec  H.242,  section  12,  should  be  followed,  with  the 
additions  described  below. 

The  MCU  transmits  the  C4I  symbol  MIC  periodically  to  all  terminals,  to  ensure 
that  they  remain  aware  of  particpation  in  the  multipoint  call. 

13.  MCU-MCU  INTERCONNECTIONS 

For  further  study.  It  may  be  difficult  to  achieve  satisfactory  operation  by 
method  (d)  of  Section  6.4,  though  other  methods  may  still  be  applicable. 
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MC'J  WITHOUT  THE  NEED  FOR  PRIMARY /SECONDARY  PORTS 


3ucn  an  MCU  will  treat  each  terminal  with  a  degree  of  independence,  by; 

-  accepting  from  terminal  Ti  only  such  signals  as  it  may  usefully  pass  on 
to  one  or  more  other  terminals;  this  "acceptance"  is  controlled  by  the 
capability  declaration  by  the  MCU  towards  Ti; 

-  transmitting  to  Ti  only  such  signals  as  Ti  can  digest,  according  to  the 
capability  declaration  by  Ti  towards  the  MCU. 

The  difference  from  the  primary/secondary  concept  lies  in  the  interpretation 
and  implementation  of  "one  or  more  other  terminals",  which  takes  the  place  of 
"all  primary  terminals". 

Some  of  the  problems  are  illustrated  here. 

(a)  In  a  call  involving  three  IB  videophones  and  two  2B+  videophones,  the 
former  would  not  receive  pictures  from  the  latter,  unless  the  MCU  included  a 
video  transcoder, 

(b)  Even  when  all  video  rates  are  the  same  a  similar  problem  arises  from  the 
range  of  video  capabilities. 

(c)  Further  complications  arise  with  the  introduction  of  data  paths  which  can 
only  be  opened  to  some  terminals. 


PROCEDURE  FOR  MCU  WITH  ISDN  BASIC  ACCESS  ONLY 


It  is  assumed  that  the  MCU  can  handle  13  or  23  connections  on  all  ports,  and 
that  the  audio  mixer  is  capable  of  AV.25d,  G.722,  and  G.tii  on  ail  ports. 

The  following  types  of  visual  telephone  are  defined  in  Rec  H.320: 

Type  Xa:  with  capabilities  A-3  and  video  up  to  46.4  kbit/s; 

Type  Xbl:  with  capabilities  A-0  and  A-3  and  video  up  to  64  kbit's; 

Type  Xb2:  with  capabilities  A-2  and  A-3  and  video  up  to  64  kb  t/s; 

Type  Xc ;  with  capabilities  A-3  and  A-2  and  video  up  to  110.4  kbit/s. 

In  fact  it  is  not  absolutely  clear  whether  Type  Xc  includes  A-2  capability, 
but  for  completeness  let  us  add; 

Type  Xc*:  with  capabilities  A-3  (and  not  A-2)  and  video  up  to  110.4  kbit/s 

We  may  also  consider  the  cases  of  two  types  not  recognised  in  H.320; 

Type  Xb3:  with  capabilities  A-2  or  A-0  (and  not  A-3)  and  video  up  to 
64  kbit/s 

Type  Xb3*;  as  type  Xb3  but  with  the  additional  capability  to  set  the  video 
rate  at  46,4  kbit/s  (Note  1). 

1.  If  there  are  not  two  terminals  with  video  capability,  go  to  9. 

2.  If  there  are  only  two  with  video  capability,  and  one  is  Type  Xa,  the  other 
type  Xb3,  go  to  9. 

3.  If  half  or  more  of  the  video  terminals  cam  tramsmit  video  at  46.4  kbit/s 
(that  is,  they  are  of  any  video  Type  except  Xb3)  go  to  5. 

4.  Since  half  or  more  of  the  video  terminals  are  of  Type  Xb3,  go  to  Outcome 
III. 


5.  If  there  are  any  Type  Xa  involved,  go  to  Outcome  II. 

6.  We  are  now  dealing  with  2B  terminals  only,  and  must  determine  which  video 
rate  is  to  be  used  (110.4  kbit/s  or  62.4  kbit/s).  If  there  are  any  terminals 
(Xb3  or  Xb3*,  or  even  Xbl  or  2  if  the  video  decoder  speed  is  limited  to  62.4 
kbit/s)  which  cannot  do  110.4  kbit/s  then  the  choice  must  be  62.4  kbit/s 
(Outcome  III). 

7.  If  all  can  do  110.4  kbit/s  but  a  majority  also  have  wideband  audio 
capability,  the  MCU  could  decide  that  better  audio  is  more  importar*  than 
better  video,  and  so  remains  with  Outcome  III. 


8.  This  leaves  Outcome  I. 


9.  There  cam  be  no  video  transmission,  so  we  treat  aii  as  audio  *  data 
terminals.  If  the  MCU  and  any  terminal(s)  nave  ML?  capability  the  appropriate 
cnannel's)  should  be  opened  ‘even  only  from  one  terminal  to  MC'J  may  serve  a 
useful  purpose). 

10.  If  two  or  more  terminals  cave  G.722  audio  then  they  use  this  ‘Outcome  IV/. 

11.  If  two  or  more  terminals  declare  2B  transfer  rate  capability  then  the  MC'J 

confirms  this  rate  on  those  connections  (Outcome  VI);  however  it  would  be 

better  for  such  declarations  only  to  be  made  after  human  or  ML?  negotiation. 

12.  Data  rate  capabilities  declared  by  the  MCU  should  be  any  common  declared 
ra”^!  within  the  bounds  of  the  "Outcomes'*  table,  preferably  negotiated  in 
ad'. -.r  oe  by  users  or  MLP. 

In  the  table  of  outcomes  it  can  be  seen  that  the  Type  Xb3  has  problems:  when 
other  terminals  are  in  the  majority,  it  is  excluded  from  the  video 
communication,  and  when  -t  is  in  the  majc  'ity  then  any  IB  visual  telephones 
are  excluded  from  the  video  communication.  The  Type  Xb3*  has  no  such  problem. 

It  would  therefore  be  well  worth  providing  for  the  BAS  command  mode  definition 
to  support  this  type  of  audiovisual  terminal. 

Notes 


(1)  To  achieve  a  video  rate  of  46.4  kbit/s  in  a  2B  connection  it  is  necessary 
to  vacate  bits  1  and  2  of  the  additional  channel,  using  anothc  '  BAS  command  to 
be  defined.  This  mode  would  ensure  that  such  a  terminal  could  inter'work  with 
a  Type  Xa  terminal  via  an  MCU,  or,  for  that  matter,  through  a  two-port  device. 

■2)  The  LSD  rates  listed  are  those  which  do  not  involve  switching  the  audio 
and  video  off,  and  must  be  common  to  at  least  two  terminals,  not  necessarily 
both  primary.  For  read  "less  than  or  equal  to". 

(3)  Video  capabilities  (QCIF/CIF  and  minimum  picture  interval)  are  declared  by 
the  MCU  at  the  highest  common  capability  (HCC)  of  the  terminals  included  as 
primary . 


TABLE  OF  OUTCOMES 


The  lebic  entries  show  the  cepnbilities  to  be  declsrd  by  the  MCU  in  the  directions  of  the  various 
types  of  terminal,  and  the  resulting  video  rate  in  italics. 


PRIMARY  SECONDARY 


OUT  COME 

Type 

T 

A 

V 

LSD 

Exclusion  T 

A 

V 

LSD 

Outcome  1 

Xc,c* 

2B 

A-3 

HCC 

<46. 4k 

n/a 

IB 

A-3,2.0 

No 

<46. 4k 

Xbl.2 

2B 

A-3 

HCC 

(llOAk) 

<46.4k 

Outcome  II 

Xa.c.c* 

IB 

A-3 

HCC 

<6.4k 

Xb3 

IB 

A-3, 2.0 

No 

<6.4k 

Xbl.2 

IB 

A-3 

HCC 

<6.4k 

Xb3* 

2B 

A-2 

HCC 

f46.4k) 

<6.4k 

Outcome  III 

Xc 

2B 

A-2 

HCC 

<14.4k 

Xa 

IB 

A-3,2,0 

No 

<14.4k 

Xhfall} 

2B 

A-2 

HCC 

<l4.4k 

Xc* 

2B 

A-0 

HCC 

(62.4k) 

<14.4k 

Outcome  IV 

A+D 

IB 

A-2 

No 

<14.4k 

IB 

A-3,0 

No 

<14.4k 

Outcome  V 

A+D 

IB 

A-3 

No 

<46.4k 

IB 

A-0 

No 

<46.4k 

Outcome  VI 

A+D 

2B 

A-2 

No 

<78.4k 

IB 

A-3,2,0 

No 

<64k 

CONSIDERATIONS  FOR  RECOMMENDATION  AV.440:  CALL-CONTROL  PROCEDURES  FOR 
REAL-TIME  AUDIOVISUAL  CONFERENCE  CALLS 
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4.1  Conference  of  Meet-me  Type 

4.2  Conference  of  Dial-out  Type 

4.3  Supplementary  Service  (Conversion  from  Point-to-Point  Call) 

4.4  Operator-Controlled  MCU 

5.  NETWORK  I.MPLICATIONS 

6.  REQUIREMENTS  ON  IN-BAND  SIGNALLING 


1.  INTRODUCTION 

Conversational  services  provide  for  real-time  speech  communication  between 
users,  aided  by  various  other  facilities  such  as  video,  telematics  and  data. 
Communication  may  be  established  between  three  or  more  audiovisual  terminals 
by  means  of  one  or  more  multipoint  control  units  (MCU)  which  handle  the 
processing  and  distribution  of  the  various  information  signals  in  an 
appropriate  way.  The  operation  of  an  MCU  is  defined  in  Rec  AV.231,  and  in 
AV.243  the  procedures  for  in-band  system  control  after  call  establishment. 

This  Recommendation  defines  a  number  of  procedures  by  which  connections  to  an 
MCU  may  be  established,  abstracting  the  network  and  in-band  signalling 
requirements  to  support  such  procedures. 

2,  TYPES  OF  CONFERENCE  CALL 

The  following  types  of  conference  call  may  be  distinguished: 

(a)  "meet-me"  type:  all  participants  dial  into  a  pre-arranged  MCU; 

(b)  "dial-out"  type:  a  convenor  dials  all  other  participants: 

(c)  supplementary  service,  in  which  a  point-to-point  call  is  diverted 
through  an  MCU  in  order  to  add  in  new  participants; 

(d)  operator  controlled:  a  non-participant,  such  as  an  employee  of  the 
service  provider,  dials  the  calls  to  all  terminals  and  transfers  them  to 
the  MCU; 

(e)  other  types  of  conference  call  may  also  emerge. 

The  use  of  conference  calls  will  not  become  widespread  unless  they  are  easy  to 
establish:  the  procedures  must  be  based  on  sound  human-factor  principles.  The 
procedures  described  in  this  Recommendation  are  for  guidance  only:  more 


important  is  the  standardisation  of  the  signals  which  facilitate  the  varici^s 
procedures.  It  is  the  responsibility  of  manufacturers  and  service  prcviders 
to  ensure  that  presentation  of  the  service  to  the  user  is  cctimised. 

Attentirn  is  drawn  to  the  need  to  provide  conference  tall  services  that  can  ce 
used  from  all  types  of  terminal,  including  simple  videopncnes  and  audio/data 
terminals  that  are  not  specially  equipped  for  conferencing.  It  is  convenient 
to  refer  to  a  basic  conference  call  between  such  terminals,  as  distinct  from 
an  enhanced  conference  call  involving  terminals  with  more  sophisticated 
capabilities . 

3.  MCU  AND  TERMINAL  CAPABILITIES 

The  capabilities  of  an  audiovisual  terminal  are  described  in  Rec  H.202,  and 
those  of  an  MCU  in  Rec  AV.231.  It  is  clear  that  in  a  conference  call  the 
communication  possibilities  may  be  limited  by  the  MCU  as  well  as  by  the  -'utual 
capabilities  of  the  participating  terminals.  The  choice  of  MCU,  at  the  time 
of  access  or  prior  reservation,  must  be  such  as  to  minimise  such  limitation; 
particular  examples  are: 

(a)  for  a  videophone  conference  call,  the  MCU  must  have  a  video  processor 
(Rec  AV.231),  and  an  appropriate  access  (IB,  2B,  HO  etc); 

(b)  for  an  audiographic  conference  call,  the  MCU  must  have  an  MLP 
processor . 

4.  PROCEDURES  FOR  CALL  CONTROL 

4.1  "Meet-me"  Type  -  All  Participants  Dial  In 

(a)  Convenor  reserves  MCU  of  appropriate  capacity  and  capability  'see 

section  3  ) .  '•* 

(b)  Convenor  notifies  particpants  of  date,  time,  duration,  and  number  to  I 

dial . 

(c)  All  participants  dial  in  at  or  just  after  the  reserved  start  time. 

(d)  The  MCU  auto-answers  each  in  turn  with  message  Ml. 

Case  1:  Simple  Terminals  and  Basic  NCU 

(el)  MCU  connects  each  terminal  into  the  conference  and  uses  M2(n)  via  the 
audio  mixer  to  announce  the  number  of  terminals  now  participating;  this 
enables  the  convenor  to  check  that  no  unauthorised  terminals  have  dialled 
in. 

(fl)  Whenever  there  is  a  change  to  the  number  of  active  ports,  M2(n)  is 
repeated  with  the  new  value  of  n. 

Case  2:  MCU  and  Convenor  Terminal  Have  MLP  Capability 

(e2)  Ml  is  followed  by  M3,  if  the  convenor  has  not  yet  dialled  in.  (NB: 
if  the  MCU  has  not  been  preset  to  expect  a  convenor  with  MLP,  M3  is 
omitted  and  the  conferees  are  added  into  the  conference.) 


(f2)  When  the  convenor  dials  in,  his  terminal  sets  up  ML?  chan.-.eL  to  cr.e 
MCU  (see  Rec  H.2^2,  .section  9.2),  which  returns  information  as  to  tns 
terminal  numbers  assigned  to  conferees  who  have  already  dialled  in  and  are 
vaiting. 

g2)  The  convenor  selects  one  terminal,  is  connected  by  audio  to  it, 
greets  the  conferee,  and  transfers  the  connection  to  the  conference  proper 
(ie,  via  audio  mixer  and  video/data  if  relevant);  he  repeats  this  until 
all  are  connected.  He  may  also  reject  a  caller  if  so  desired. 

(h2)  The  MCU  keeps  the  convenor's  terminal  informed,  via  the  MLP,  of  tr.e 
status  of  its  ports.  At  any  time,  the  convenor  may  disconnect  a  terminal 
from  the  conference,  and  either  speak  directly  to  that  conferee  or  clear 
down  his  call  altogether. 

Case  3:  MCU  and  Some  or  All  Terminals  Have  MLP  Capability 

(e3)  Each  MLP-capable  terminal  establishes  a  dialogue  with  the  MCU, 
assigning  terminal  numbers,  location  and/or  conferees'  names  ('and  perhaps 
associated  microphone  identifiers)  and  so  on. 

(e4)  The  terminals  may  be  connected  immediately  into  the  conference 
proper,  without  waiting  for  the  intervention  of  the  convenor,  or  the  MCU 
may  be  set  to  preclude  this  if  specified  at  the  time  of  booking. 

(f3)  The  convenor  is  identified  by  insertion  of  a  password  obtained  at  the 
time  of  booking.  The  convenor  may  disconnect  terminals  from  the 
conference,  as  in  (h2)  above;  he  may  take  later  calls  to  the  conference, 
with  or  without  adding  them  in.  The  convenor  may  release  his  role  to 
another  conferee  by  passing  him  the  convenor  "token",  using  the  MLP. 

Messages 

Ml:  This  is  an  automatic  conference  control  unit. 

M2(n):  The  number  of  terminals  now  connected  (to  the  conference)  is  n. 

M3:  Please  wait  to  speak  to  the  convenor. 

M4:  Your  terminal  is  number  1;  other  terminals  will  be  numbered  in  the 
order  they  are  connected  (to  the  conference). 

M5:  To  add  another  conferee  at  any  time,  please  key  #  followed  by  the 
( long<>dlstance )  code. 

M6:  Please  now  begin  calling  the  other  conferees. 

M7(n):  Terminal  n  has  just  been  disconnected. 

Note:  experienced  users  may  be  annoyed  if  they  have  to  wait  for  the 
messages  M4-M6  to  be  completed  before  they  can  continue;  therefore  the 
system  should  be  such  that  no  waiting  is  necessary,  and  messages  are  cut 
off  as  soon  as  the  convenor  begins. 


4.2  "Dial-out"  Type  -  The  Convenor  Dials  All  Conferees 


a  ,1  The  convenor  identifies  (via  the  service  provider'  an  MC'J  of 
appropriate  capacity  and  capability  (see  section  5  '  a-d  reserves  it  if  II 

"ecessary . 

b)  The  convenor  notifies  participants  of  date,  time  and  duration. 

(c)  The  convenor  dials  the  MCU  at  the  appointed  time. 

Case  1 :  Simple  Terminals  and  Basic  MCU 
' dl )  The  MCU  auto-answers  with  message  Ml. 

(el)  Messages  M4,  M5,  M6  follow. 

( f 1 )  The  convenor  dials  the  conferees  in  turn. 

(gl)  On  answering,  each  conferee  is  immediately  connected  into  the  (audio 
bridge  or)  conference  proper;  he  identifies  himself  as  he  would  for  a 
telephone  call. 

(hi)  If  the  convenor  is  not  satisfied  as  to  the  suitability  of  a  conferee 
to  participate,  he  must  key  something  unmistakable  (such  as  three  or 
more*)  followed  by  the  terminal  number. 

(il)  If  for  any  reason  a  terminal  is  dropped  from  the  MCU,  the  message 
M7(n)  is  heard. 

Case  2:  MCU  and  Convenor  Terminal  Have  MLP  Capability 

'd2)  The  MCU  auto-answers  and  an  MLP  channel  is  set  up  ( Rec  H.242,  Section 
9.2);  instructions  are  sent  to  the  convenor  to  guide  him  through  the 
process  of  dialling  the  other  conferees,  following  the  same  routine  as  for 
Case  1  above. 

(e2)  The  convenor  may  choose  to  speak  to  called  conferees  individually 
before  adding  them  to  the  conference  proper. 

4.3  Supplementary  Service  to  a  Point-to-Point  Call 

tb 

(a)  Terminal  A,  spesd<ing^B  and  wishing  to  add  C  and  D,  first  forces  Mode  0 
(see  Rec  H.242,  Section  6.2)  and  suspends  the  call  to  B. 

(b)  A  dials  an  MCU  of  dial -out  type  and  suitable  capacity  (see 

Section  3  )  -  this  may  involve  keying  "Conference"  or  another  combination  * 

if  the  MCU  is  attached  to  the  local  exchange;  if  A  and  the  MCU  both  have 
MLP  capability,  this  chjuinel  may  be  established  to  facilitate  further 
action,  otherwise  message  Ml  is  heard. 

(c)  Terminal  A  or  its  local  exchange  must  detect  the  D-channel  message 
completing  the  MCU-A  connection,  amd  must  then  forward  the  terminal-B 
connection  to  a  second  port  of  the  MCU  capable  of  auto-answer  (despite  the 
MCU  being  "dial-out"  type). 

(d)  Both  terminals  now  hear  messages  M4-M6  but,  to  avoid  the  possibility 
of  contention,  only  the  first  to  key  #  is  acted  upon;  the  other  is 
ignored. 


(e)  The  conference  call  proceeds  as  in  Section  2  (dl)  to  iil)  above. 
J .  -i  Operator-Control Igd  MC'J 
To  be  completed. 

5.  NETWORK  IMPLICATIONS 


The  design  of  the  general  audiovisual  system  is  such  that,  despite  the  wide 
variety  of  applications  foreseen,  the  special  requirements  of  the  network  are 
kept  to  a  minimum. 

5.1  HLC  and  LLC 

It  is  a  prerequisite  that,  where  a  connection  between  two  equipments  is 
requested,  it  should  be  completed.  I.n  the  general  case,  when  a  user  A 
calls  another  (B)  he  may  be  unaware  of  the  exact  type  of  audiovisual 
terminal  possessed  by  3;  likewise  B  is  unlikely  to  decline  to  answer 
simply  because  A's  audiovisual  terminal  is  different  from  his  own.  In 
this  context  "audiovisual"  should  be  taken  to  include  audio-only 
terminals  -  narrowband  and  wideband  telephones. 

In  the  same  way,  the  MCU  cannot  be  aware  of  the  exact  types  of  the 
audiovisual  terminals  it  is  calling,  in  the  dial-out  case,  nor  of  those 
dialling,  in,  in  the  meet-me  case. 

There  is  therefore  a  strong  case  for  the  use  of  a  generalised  audiovisual 
HLC  in  the  call-control  process,  together  with  LLC  of  "unrestricted 
digital"  (or  perhaps  "7kHz  bearer"  if  this  solves  the  problem  of 
interworking  with  PSTN  telephones). 


5,2  Supplementary  Service 

A  method  is  required  whereby  a  caller  connected  to  another  party  is  able 
to : 


(a)  key  "M"  to  suspend  his  connection  to  the  other  party  and  either  (i)  be 
automatically  connected  to  a  suitable  MCU,  or  (ii)  dial/autodial  the 
numcer  of  a  suitable  MCU; 

(b)  when  the  MCU  is  connected,  either  (i)  he  keys  "Z"  or^^his  terminal 
recognises  that  the  MCU  has  answered  and  acts  as  if  "Z"  had  been  keyed; 

(c)  the  local  exchange  recognises  the  "Z"  command,  and  re-routes  the 
original  called  party  to  another  port  of  the  MCU; 

(d)  the  caller  then  keys  "X"  to  suspend  his  connection  to  the  MCU,  holding 
it  at  the  local  exchange; 


(e)  he  dials  the  number  of  another  party; 


(f)  when  the  other  party  answers,  either  (i)  they  speak  first,  and  the 
caller  then  again  keys  "Y",  or  (ii)  the  calling  terminal  recognises  that 
the  other  party  has  answered  and  acts  as  if  "Y"  had  been  keyed,  without 
waiting  for  either  party  to  speak; 


(g)  the  local  exchange  recognises  the  "Y”  command,  disconnects  these  t-vo 
parties  from  each  other  and  connects  both  to  the  MCU  (the  original  raller 
"ist  be  restored  to  the  same  MCU  port  as  before). 

I'  may  be  noted  that  b(ii)  has  the  advantage  of  greater  simplicity  fcr  tr.e 
iser.  The  choice  of  keys  K  and—V  and  of 5iii)/(ii)  are  a  matter  for  tne 
terminal  designer.  M  x"  y  Z 

6.  .REQUIREMENTS  ON  IN-3AND  SIGNALLING 

6.1  "Meet-me"  Type  MCU 

Using  MLP  a  wide  variety  of  procedures  is  possible. 

Basic  terminals  and  MCU  do  not  have  this  capability.  The  use  of 
recorded/synthesised  speech  for  status  indications  from  the  MCU  obviates 
the  need  for  defining  more  C&I  symbols,  and  for  terminals  to  recognise  and 
use  them. 


6 . 2  "Dial-out"  Type  MCU 

The  dial-out  MCU  could  be  designed  to  set  up  calls  to  other  terminals  from 
each  of  its  ports,  but  would  need  to  obtain  from  the  convenor  the  numbers 
to  be  called.  This  is  no  problem  if  the  convenor  and  MCU  have  MLP 
capability,  but  poses  a  problem  if  the  convenor  has  only  a  basic  terminal 
(not  specifically  designed  for  conferencing).  Part  of  the  procedure  of 
section  5.2  would  be  applicable  (points  (d)  to  (g)  but  may  be  difficult  to 
implement  when  the  MCU  is  not  attached  to  the  convenor's  local  exchange'. 

Other  possibilities  are: 

a)  Speech  recognition  in  the  MCU,  to  accept  a  verbal  input  for  numbers  to 
be  called; 

lb)  A  basic  terminal  may  be  designed  such  that,  when  a  call  is  in  progress 
and  H.221  framed  transmission  is  being  used,  keying  0-9,  #,  *  results  in 
the  transmission  of  a  corresponding  Cil  symbol,  to  be  specified  in  Rec 
H.230, 
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